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SECTION I 
INTRODUCTION 


1.1 PURPOSE 

This document was prepared by McDonnell Douglas Space Systems (MDSS) under 
Contract NAS 10-1 1400 to National Aeronautics and Space Administration - Kennedy 
Space Center (NASA-KSC). The purpose of this document is to provide a clear 
understanding of the Test, Control and Monitor System (TCMS) operating environment 
and to describe the method of operations for TCMS. TCMS is a complex and 
sophisticated checkout system focused on support of the Space Station Freedom Program 
(SSFP) and related activities. 

This document provides an understanding of the TCMS operating environment and 
defines operational responsibilities. NASA and the Payload Ground Operations 
Contractor (PGOC) will use it as a guide to manage the operation of the TCMS computer 
systems and associated networks and workstations. 


1.2 SCOPE 

This document examines all TCMS operational functions. Other plans and detajltd 
operating procedures relating to an individual operational function are referenced within 
this plan. This plan augments existing Technical Support Management Directives 
(TSMDs), Standard Practices, and other management documentation which will be 
followed where applicable. 

For the purpose of this document, "User" is defined as a member of the KSC test 
engineering, applications, or simulation software development organizations. Users are 
responsible for developing test software, simulation software and conducting a 
coordinated test of flight hardware and Ground Support Equipment (GSE). "Operations 
Engineer" or "Master Console Operations Engineer" is defined as a member of the TCMS 
Operations and Maintenance organization and is responsible for the Operations of TCMS 
set equipment 

Also, for the purpose of this document "Operations" is defined as all Operations and 
Maintenance activities that are required to ensure the continuous functioning of TCMS. 
These functions include: 


Master console operations; 

Computer operating system software and network operations; 
System maintenance; 
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• Database administration and file management; 

• Hardware and set resource configuration control; 

• Performance assessment and improvement; 

• System and network security; 

• Software Production Facility (SPF) and Global Operations Facility (GOF) 
operations. 

Also included within the definition of "Operations" are the following support services: 

• Anomaly verification and testing of TCMS hardware and software; 

• Train support personnel; 

• User support (TCMS Client Support Area); 

• Preparation of procedures and policies; 

• Security and disaster recovery plans; 

• Tracking of the work necessary to ensure that TCMS Customer Service Requests 
(CSRs), Interim Problem Reports (IPRs), and Problem Reports (PRs) are correctly 
dispositioned. 

The following terms, when used in this document, refer to groups consisting of the 
appropriate NASA and PGOC TCMS personnel: 

• Operations and Maintenance (O&M); 

• Logistics; 

• Space Station Payload Software Engineering (SSPSE); 

• Safety, Reliability and Quality Assurance (SR&QA); 

• Software Product Assurance (SPA); 

• Sustaining Engineering (SE). 

1.3 CEC SET SUPPORT TEAM 

While the Core Electronics Contractor (CEC) contract is still in effect, the CEC will 
provide a Set Support Team (SST). This team will help NASA and PGOC operate and 
maintain TCMS. SST will provide assistance to O&M as well as other organizations. It is 
assumed throughout this document the SST is an integral part of TCMS O&M 


1.4 DOCUMENT ORGANIZATION 

This document is organized into the following nine sections: 
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Section 1 - Introduction 

Section one introduces the TCMS Operations plan by including the purpose, scope, 
and organization of the document It also lists reference documents where more 
detailed information on specific topics can be found. 

Section 2 - System Support 

Section two states the goals of TCMS O&M and how they will be measured. This 
section also discusses the organization and responsibilities of the TCMS Utilization 
Group (TUG). 

Section 3 - Operations 

Section three discusses the different operational elements of TCMS. It gives a brief 
summary of the elements along with their operational components and how they will 
be operated. The TCMS Master Console functionality. Client Support Area, work 
tracking and control, shift operations, and system configuration are described. 

Section 4 - Resource Management 

Section four discusses resource management of TCMS. 

Section 5 - Performance Management 

Section five discusses the TCMS O&M performance goals and objectives and states 
how O&M will ensure they are satisfied. 

Section 6 - Anomaly Verification and Testing 

Section six discusses the maintenance responsibility of O&M and how operations 
personnel will work with maintenance personnel to correct hardware and software 
anomalies. It includes part of the paper trail associated with the maintenance work as 
well as who is responsible for maintenance on which subsystems. General scenarios 
are given to show the TCMS maintenance flow. Specific maintenance information is 
not discussed here but in the TCMS Maintenance Plan, TS-TCMS-92003. 


Section 7 - Training 

Section seven states the TCMS training objectives and who is responsible for training 
O&M personnel 

Section 8 - System Administration 

Section eight states die roles and responsibilities of system administration. It includes 
a list of tasks die system administrator will carry out on an as needed, daily, weekly, 
monthly and occasional basis. System administration also includes security, database 
and resource scheduling. 
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Section 9 - Risk Assessment 

Section nine discusses how TCMS O&M will develop and cany out a disaster 
recovery plan. The section states risks TCMS will be susceptible to as well as 
emergency preparedness. 


1.5 REFERENCE DOCUMENTS 


a. 

K-CIE-50.1 Rev B. 

TCMS Operations Concept Document 

b. 

TS-TCMS-92001 

TCMS Operations and Maintenance 
Philosophy 

c. 

TS-TCMS-93xxx 

TCMS Security Plan 

d. 

TS-TCMS-92003 

TCMS Maintenance Plan 

e. 

TS-TCMS-92004 

TCMS Communication and Patching Plan 

t 

TS-TCMS-93xxx 

TCMS Database Management/Systera 
Administration Plan 

g- 

KSCM-DL-01 12 

TCMS ACT/VAL Management Plan 

h. 

TBD 

TCMS Sustaining Engineering Plan 

L 

TBD 

TCMS Disaster Recovery Plan 

j- 

TBD 

System Operations and Maintenance Manual 
for the Cargo Integration Test Equipment 

k. 

K-CTE-63.2 

TCMS Production Control Plan 

L 

SP10.001-A91 

Nonconfonnance/Problem Reporting and 
Corrective Action (PRACA) System 

m. 

KHB-1040.1D 

Emergency Preparedness Plan 

n. 

KMI 1620.5 A 

Bombs and Bomb Threats 

0 . 

KMI 8838. IB 

Fire Protection, Fire Prevention and Rescue 

P- 

KHB 1040.2F 

KSC Hurricane Handbook 

q- 

KSC-STA-61.07 

Facility Equipment Requirements 
Document/Design Plan 
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SECTION n 
SYSTEM SUPPORT 


2. 1 STATEMENT OF GOALS 

The goal of TCMS O&M is to provide reliable, uninterrupted system support for TCMS 
in order to facilitate the test and checkout of SSFP test articles and subsystems. This 
primary goal will be attained through the following sub-goals. 

• TCMS Set Availability; 

• Reconfiguration Time; 

• Network Availability; 

• Service Request Cycle Time; 

• Service Request Volume; 

• Anomaly Metrics. 

Note: Goals are TBD pending analysis of final TCMS system design. Separate Service 
Level Agreements will be drafted and agreed upon before first set installation at KSC. 


2.2 GOAL MEASUREMENT 

ICMS Set Availability is measured per end item test Availability for each subsystem of 
the TCMS set is averaged to provide an overall set availability. The subsystem availability 
is computed as the 'up time' for the duration of the test period. 

Reconfiguration Time is the time it takes to configure the TCMS set for an end item test 
The aggregate times for hardware allocation, patching, software loads, and validation are 
included in reconfiguration time as well as the size of the set being reconfigured. 

Metwork Availability is the continuously measured 'up time' of each TCMS network. 

Each area supported by the network is tracked separately. From these separate 
measurements an overall availability is computed. A set availability and overall TCMS 
availability will be computed. 

ScrYlCg Request Cycle Time includes IPR, and CSR response cycle time. The amount of 
time that is required to close and document an IPR, CSR or nonconformance is tracked to 
allow performance to be measured and improved. 

Service Request Volume is a measure of the number of IPRs and CSRs that are opened, 
and how many were closed in a given period. 
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Anomaly Metrics is a percentage-based list of anomalies encountered during TCMS 
operation to the total number of defects encountered. 

A descriptive comparison between reconfiguration and availability will be developed to 
show how each affects the others resources. 


2.3 SYSTEM AVAILABILITY 

The implementation of system availability reporting is required for the measurement and 
comparison of data relative to the overall availability of TCMS systems. System 
availability is the first step in an ongoing process that will provide comprehensive 
reporting and statistical data analysis required for continuous improvement 

System availability time is defined as the time that the system is available for productive 
use. Productive use includes the time for normal testing as well as the time to accomplish 
scheduled overhead events required to support production, during which the users do not 
have access to the system. These activities generally occur on a daily, weekly, or monthly 
schedule and in some instances, may occur on an as-required basis. These activities are 
normally scheduled on third shift or between tests so not to inhibit user activities. 

The system availability (S A) percentage is derived by the formula: 

SA% = (1 - (U/(BT-S))) * 100 

Where U equals unscheduled outage time, BT equals base time, and S equals scheduled 
outage time. 

The following definitions apply: 

Unscheduled outage time (U) is the unplanned or unforeseen events that remove the 
system from productive use. 

Base Time (BT) equals the time that the systems should be functional In the case of 
TCMS, that functionality is defined as 24 hours a day, seven days a week. 

Scheduled outage time (S) is the planned events that remove the system from productive 
use and for which the user community has been given adequate notice. Every attempt is 
made to schedule this category of outage during off-shift hours. It must be recognized, 
however, that due to third party contractual agreements or constraints this may not always 
be possible. 
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The formula decrements the base time by scheduled outage time. In doing so the formula 
recognizes that SA% should not be reduced unrealistically by efficient scheduling of 
required activity. Therefore, the O&M organization should pay careful attention to 
scheduling requirements and coordination of those events with the user community. 

Long standing industry and government standards recognize that unscheduled outage time 
of an efficient data processing organizations' base time typically equals 3.0% or less. This 
leaves a service level objective of 97.0% for system availability. However, the TCMS 
requirement is slightly lower with the system availability objective being 96%. 

The following sample calculation illustrates the method for calculating the system 
availability percentage: 

Base Time (BT) = 168 hours 
Scheduled outage time (S) = 25 hours 
Unscheduled outage time (U) = 3.58 hours 

SA% = (1 - (U / (BT - S))) * 100 

SA% = (1 - (3.58hrs / (168hrs - 25hrs))) * 100 

SA = 97.5% 

System availability should not be confused with prime shift availability or the ratio of 
overhead (administrative) processing to overall availability. The reporting of those 
statistics is intended to be an outgrowth of this reporting system and will req uir e 
additional developmental effort 

Log entry — The person in charge of the system during the event whether 
Operations Engineer, system manager, or vendor representative is responsible for insuring 
the proper entries are made in the TCMS Availability Log. 


Administrative — A designated person shall be responsible for daily monitoring 
and follow-up of the logs to insure that entries are complete and correct The same 
person shall ensure that a supply of forms is available at each Master Console. When the 
log is complete for the period, the designated person will perform the data entry function 
and produce the appropriate reports. 

Management - Management should review the logs and shall have final 
responsibility for determining how a questionable event should be logged. 
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2.4 TCMS UTILIZATION GROUP 

The TUG is composed of personnel from operations, maintenance, administration, 
sustaining engineering, logistics, software development, quality assurance, software 
product assurance, and the user community to discuss and resolve TCMS operational 
issues. The overall desired effect is rapport and mutual assistance throughout TCMS. 

The TUG will identify, study, and recommend solutions to issues related to TCMS O&M 
performance. TUG activities will be coordinated with appropriate directors and 
departments throughout NASA and PGOC and will consist of: 

• Resolving TCMS hardware and system software processing problems and 
inefficiencies; 

• A forum for resolving O&M scheduling difficulties; 

• Coordinating support of user activities; 

• Planning for peak resource demands or TCMS resource modifications. 

2.4. 1 RESOLVING TCMS PROCESSING PROBLEMS AND INEFFICIENCIES. 

Considerable time and effort can be wasted during test and checkout because of 
application-system problems and wasteful use of TCMS resources. The problems may 
include frequent restarts and difficulty in verifying proper completion of jobs. 
Inefficiencies include poor test design, material shortages, scheduling, overtasking of 
resources, etc. 

With rapport established in the TCMS community, various alternatives to improve the 
existing processing method can be considered. For example, the users can provide input 
to their department, thus addressing solutions to problems where the most-informed 
persons for the appropriate applications are located. 

The TUG meetings will be held monthly, or more frequently if required. The TUG O&M 
chairperson is responsible for distributing meeting notices with adequate lead time to 
encourage meeting attendance. Minutes will be taken at all meetings to retain a history of 
the activity performed and the actions taken. The TUG chairperson or designee is 
responsible for preparation and distribution of meeting minutes. 


2.4.2 RESOLVING SCHEDULING DIFFICULTIES. TUG members will help plan 
how to meet schedules, identify and resolve conflicts, and prioritize the TCMS work load. 
They will provide PDMS-based automated scheduling systems with the rules, 
dependencies, and logic, to resolve TCMS scheduling problems. The 72 hour, 1 1 day 
schedule will be used for TCMS processing and utilization. 


2-4 


TS-TCMS-92002 
Rev Basic 
January 29, 1993 


2.4.3 COORDINATING USER ACTIVITIES. TUG members will resolve any user 
problems that arise. The TUG will then assign a task team made up of personnel from 
each division to analyze the problem by establishing and documenting procedures used for 
resolution. 


2.4.4 PLANNING FOR PEAK RESOURCE DEMANDS OR TCMS RESOURCE 
MODIFICATION. Many times, managers of large computer systems similar to TCMS 
have been surprised by the unexpected demands on the systems resources and problems 
with hardware and software because of a lack of planning and co mmu nication. By 
increasing communication, die TUG will minimize unplanned situations that would 
interfere with the test and checkout of test articles. 
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SECTION m 
OPERATIONS 

-TCMS O&M has the primary responsibility to support operations of TCMS. The goal of 
this group is to provide reliable, uninterrupted system support to all TCMS customers. 
TCMS Operations are categorized as: 

• Master Console operations (paragraph 3.1); 

• Computer room operations (paragraph 3.2); 

• Operational services (paragraph 3.3); 

• Work tracking and control (paragraph 3.4); 

• Operations at Core Electronics Contractor site (paragraph 3.5); 

• Central Software Facility/Central Avionics Facility Operations at Johnson Space 
Center (paragraph 3.6). 

Along with the above topics, operations personnel are responsible for the following: 

• Resource Management (section 4); 

• Scheduled and corrective maintenance activity support (section 6); 

• Error detection and problem resolution (paragraph 6.1) 

• System Administration for TCMS sets and hosts(section 8); 

• Host and Network Security (paragraph 8.2) 

• Database Administration (paragraph 8.3). 

3. 1 TCMS MASTER CONSOLE 

The TCMS Master Console Area, located in the TCMS Control Room, is the nerve center 
for TCMS. All O&M activity stems from this area. The master console is made up of 
workstation housings, workstation tables. Operational Intercom System - Digital (OIS-D), 
Display Processors, Payload Office Workstations, and laser printers. The workstation 
housings are joined to form a circular area where all Master Console operations are 
performed. 

The Master Console Operations Engineers (MCOEs) arc responsible for the following 
TCMS functions: 

• Configuration of TCMS hardware and software; 

• Monitoring all system messages; 

• Monitoring TCMS health and status; 

• TCMS Hardware and software error detection; 

• Execution and support of scheduled and unscheduled events; 
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• Generating, logging and tracking TCMS problem reports; 

• Satisfying all system requests including printing and mounting requests. 

The Master Console Area also includes the Client Support Area functionality. The Client 
Support Area is located in the center of the Master Console Area. The Client Support 
Area serves as the link between the users and the O&M personnel. For further 
information on the Client Support Area, see paragraph 3.3. 

Figure 3-1 below shows the Master Console Area and its components. 


Master Console DP Workstation 
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The Master Console Area contains fourteen DPs. O&M assumes the Master Console 
Operations Engineer (MCOE) can actively view four windows per Display Processor 
(DP). The set master. Test Resource Set (TRS) master. Network Manager (NMG), and 
an individual TRS each require one window. The Master Console DPs are distributed in 
the following manner 

Note: Currently, DPs can only view one TRS at a time. This section assumes that this 
will change and multiple TRSs will be available to one Master Console DP. 


HALF SET 

# OF DPs 

HALF SET 

# OF DPs 

Al 

2 

C2 

1 

A2 

2 

GOF 

1 

B1 

4 

SPF 

1 

B2 

2 

PSTF-R 

*1 

Cl 

1 

CAF 

*3 


* - DPs not included in the fourteen Master Console DPs. 

B1 - Four DPs have been allocated to the B 1 half set These DPs are required to support 
die number of TRSs possible during software development Baseline configuration allows 
the B1 set to have at most nine concurrent TRSs including combinations of the following: 

• Three Simulation test pairs (6 TRSs - 6 windows) 

• Three "Buffer Stuffers" (3 TRSs - 3 windows) 

• Set Master (1 window per set) 

• TRS Master (1 window per TRS) 

• Network Manager (1 window per set) 

Assuming an MCOE can actively view four windows from one DP, four DPs will cover 
die required number of windows needed. 

Al, A2, B2 - Two DPs have been allocated to each of the Al, A2, and B2 half sets. 

These half sets will be the main sets used for hardware testing. Normally, no more than 
three TRS's will be concurrendy active on any of the three half sets. Active display 
windows include combinations of the following: 

• Three TRSs (3 TRSs - 3 windows) 

• Set Master (1 window per set) 

• TRS Master ( 1 window per TRS) 

• Network Manager (1 window per set) 

Assuming an MCOE can actively view four windows from one DP, two DPs would cover 
a minimum configuration in any of the half sets Al, A2, B2. 
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Cl, C2 - One DP has been allocated to each half set in set C. This set does not include 
equipment that will allow more than one TRS to be active per half set The DP will be 
used to display the following windows: 

• One TRS (1 window) 

• Set Master (1 window per set) 

• TRS Master (1 window per TRS) 

• Network Manager (1 window per set) 

Assuming an MCOE can actively view four windows from one DP, one DP per half set 
will cover the configuration of set C. 

GOF, SPF - The GOF and SPF will need a minimum of one DP each to run the Network 
Manager software. Also delivered with each Database Subsystem (DBS), Processed Data 
Recorder (PDR), and Host are terminal class machines connected directly to the console 
port of the box. These consoles are used for retrieval status as well as operations and 
maintenance functions. 

PSTF-R - PSTF-R will require a minimum of one DP to run Network Manager and view 
the active TRS. 

CAF - As of the PDR for the CAF, three DPs are allocated to the CAF Master Console. 

There are currently no DPs available as spares or as maintenance and troubleshooting aids. 
When an anomaly occurs within a set, the sets MCOE will have to troubleshoot the 
anomaly as well as monitor the remainder of the set from the same DP. Otherwise an 
operator will have to 'take over 1 one or more of the windows from a DP to allow for 
troubleshooting or maintenance. This could impact the repair time if the operator is 
heavily involved in troubleshooting of the particular anomaly. 


3.2 COMPUTER ROOM OPERATIONS 

TCMS O&M has the primary responsibility to support operations of the TCMS computer 
facility. The goal of this group is to provide reliable, uninterrupted computer support to 
all TCMS personnel. The specific functions and how each is performed will depend upon 
die final configuration provided by the CEC. 

TCMS O&M operates the TCMS computer systems and associated peripherals, performs 
system backups, schedules preventive maintenance with the original equipment 
manufacturer (OEM) or internal maintenance personnel, monitors system activity, verifies 
job execution, responds to user inquiries, performs set configuration/reconfiguration, and 
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performs software downloads. Most operations are executed from the TCMS Mas ter 
Console Area. See paragraph 3. 1 for information on the TCMS master console. 

Computer room operations are further divided into the following paragraphs: 

• Active Sets (paragraph 3.2.1); 

• Payload Spin Test Facility - Replacement (PSTF-R) (paragraph 3.2.2); 

• Software Production Facility (SPF) (paragraph 3.2.3); 

• Global Operations Facility/Processed Data Recorder (GOF/PDR)(paragraph 3.2.4); 

• Data Management System (DMS) Kits (paragraph 3.2.5); 

• Communications and Patching (paragraph 3.2.6); 

• User Rooms (paragraph 3.2.7); 

• Cargo Integration Test Equipment (paragraph 3.2.8). 

Each section describes the operational functions for its respective set or group of sets. 


3.2.1 ACTIVE SETS. Active Sets include half sets Al, A2, Bl, B2, Cl, C2, and the 
hazardous set (PSTF-R). An "active set" is one of the half sets currently supporting or 
being configured to support software development, training, or testing of a flight hardware 
article. A half set is composed of the group of hardware and software needed to test a 
flight article or GSE including: 

• Core provided hardware, software, and patch fields; 

• DMS Kit provided hardware, software, and patch fields; 

• Intermediate bay hardware and patch fields; 

• Highbay hardware and patch fields; 

• Facility provided hardware. 

Operational activities are executed by the set MCOE on the set Master Console DP 
located in the TCMS control room. 


3.2.1. 1 Active Set Operatio nal Components . Each active set is cnmpngftH nf mv» nr 
more of the following baseline hardware component's and its associated software: 

• AP 

• DP 

• Master Console DP 

• PDR 

• FEP's 

• HIM's 

• RTN 
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• CDBFR 

• Bridges 

• Routers 

• DMS Kits 

• Patch fields 

• Facility hardware 

For detailed information on any of the active set components, see the specific Core 
Configuration Item (Cl) documentation. 


3.2. 1.2 Active Set Operations . The set's MCOE will be responsible for operations of 
all the set components including operator level preventive maintenance, set initialization, 
software downloading, system software loading, monitoring system activity, responding 
to user inquiries, error detection, event initiation, set configuration, set configuration 
updates, and supporting active tests. In addition, operations and communications 
personnel will maintain bridge and router configurations. 


3.2.2 HAZARDOUS OPERATIONS FACILITY. The Hazardous Operations 
Facility (HOF) includes the TCMS active set designed for hazardous operations. It is 
composed of the PSTF-R and the Hazardous Operations Support Facility (HOSF). The 
user control room and user DPs for the HOF will be located in the HOSF. HIMs and 
distance sensitive FEPs will be located in the PSTF-R. All other set equipment and the 
master console DP will be integrated in the Space Station Processing Facility (SSPF) with 
die other Core equipment Operational activities will be executed by the set MCOE on the 
set Master Console DP located in the TCMS control room. 


3.2.2. 1 Hazardous Operations Facility Operational Components . HOF operational 
components are identical to the active set operational components. See paragraph 3.2. 1.1 
above. Additionally, the HOF is equipped with safety equipment to shutdown hazardous 
operations should the need arise. 


3.2.2.2 Hazardous Operations Facility Operations . TCMS O&M will operate the HOF 
consistent with Active Set Operations, paragraph 3.2. 1.2 above. 


3.2.3 SOFTWARE PRODUCTION FACILITY. The SPF includes the set of 
hardware used for development and configuration management of applications and 
simulation software. SPF allows software developers to perform final compiles on the 
target subsystems. It serves as a local repository for downloaded Master Object Database 
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(MODB) data, build data, and test configuration functions. Several databases are also 
located on the SPF. For information on the databases see paragraph 8.3 of this document 


3.2.3. 1 Software Production Fa cility Operational Components . The SPF is composed 
of die following baseline equipment: 

• Host Computer Systems 

• Cluster Controller-to-Disk Drive Interface 

• Disk Drive Storage Unit 

• Tape Drives 

• Target AP 

• Target PDR 

• Target DBS 

• Line Printers 

• Master Console DP 

• SPF Host Console (attached to host console port) 

For a detailed description of the SPF equipment see the Core Hardware Design and 
Maintenance documentation for the Software Production Facility, 83K03802. 


3-2.3.2 Software Production Facility Operations . The anticipated SPF workload 
consists primarily of databases functions, software development and build activities, 
reports concerning these activities, and maintenance of the delivered Core developed 
software. The SPF will be available for users 16 hours per day, 5 days per week. 
Preventive maintenance and backups will be performed during third shift. 

For detailed information on specifications, installation, operations, and maintenance of the 
SPF and its components, see the Core Hardware Design and Maintenance documentation, 
83K03820. 


3.2.3.2.1 Host Operations. Startup of the Host systems is automatic. Once the disk 
drives and Central Processing Unit(s) are powered on, the system will autoboot All 
configured devices will come up along with all installed layered software products. If a 
hardware or software problem should develop, a message indicating the problem and the 
severity level is sent to the host console. If the system can continue to run it will due so; 
however, if the operating system determines that the error will compromise the integrity of 
tiie system, the system will crash. If a crash occurs the system will record all necessary 
debug information in a dump file before it halts. The system will then re-boot itself. It is 
the responsibility of O&M and the computer vendor to troubleshoot a system crash. If 
there is a power spike or fluctuation, the system will re-boot itself. However, the SPF is 
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powered by facility Uninterruptible Power Supply (UPS) making power fluctuations 
minimal. 

Once the system is up and running, operator intervention is minimal and the system will be 
operated according to vendor documentation. The System Administrator will be 
responsible for the creation and deletion of users as well as system tuning through the use 
of tools to monitor and adjust its performance (Le., SYSGEN, a subsystem of the 
operating system). 


3.2.3.2.2 Host Backups . Backups are planned to be performed using the VAX/VMS 
BACKUP command. This command will provide for an on-line backup, thereby negating 
the need for system downtime while backups are being performed. System performance is 
only minimally degraded by this operation. This backup methodology copies all files that 
are not being accessed, to tape. If the file is open for access, the operating system makes 
a "best guess" attempt to copy the file to tape. A warning message is issued indicating 
that this has occurred. The operator will be prompted to mount tapes as needed to 
complete the backup. 

Incremental backups will be performed on a daily basis with full system backups occurring 
on a monthly basis. Backups are performed as part of third shift operations and will not 
preempt flight testing or other scheduled events. A subset of the media library will exist 
off-site where the storage of first generation backups will be maintained. The third shift 
Operations Engineer is responsible for performing the backups and maintaining the off-site 
media library. 

Note: The location of the offsite storage area is TBD. 


3.23.2.3 Cluster Controller-to-Disk Drive Interface Operations . The cluster controller- 
to-disk drive interface, once configured, will require no operator intervention. Any 
maintenance will be provided by the vendor. 


3.23.2.4 Disk Drive Storage Unit Operations . The disk drives supplied with the SPF 
will require no operator intervention. Once the drives are powered up and have been 
placed on-line by the front panel button they require no attention. 

A second type of backup operation will need to be performed to defragment the disks. 
This operation will be performed as needed, based on the amount of disk fragmentation. 
To defragment a disk the system must be completely shutdown and re-booted using the 
standalone Backup kit This boot configuration brings the system up in a minimal, single- 
user state. Once the system has been booted in this configuration the disk to be 
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defragmented is copied to tape using the /IMAGE qualifier of the BACKUP command. 
This command copies all files to tape contiguously. Another backup is then performed in 
which the files are copied from tape to disk. At this point the disk has been defragmented 
and the system should be shutdown and re-booted in its normal configuration. 


3.2.3.2.S Other SP F Device Operations . All other SPF host devices will be operated 
consistent with their respective vendor documentation. The target devices will be 
operated consistent with their vendor and Core documentation. 


3.2.4 GLOBAL OPERATIONS FACILITY / PROCESSED DATA RECORDERS. 
The GOF consists of two DBS connected by the GOF Global Display Bus to the TCMS 
Global Bus. Sets A, B, C, and PSTF-R access the GOF through the TCMS Global 
Display Bus. The GOF also contains routers and gateways to manage TCMS external 
network communications and the connection of the DBSs and SPF to Payload Operations 
Network (PON) users and external networks. Users working from POWs are granted 
access to TCMS data through the GOF routers and gateways. 

Note: The security ESR that allows PON access to TCMS data is not yet approved. 
Should the ESR fail to be approved, PON access will be deleted due to security risks. 

Each DBS within the GOF supports the following functions: 

• Manage retrieval requests. 

• Maintain knowledge of the location of all recorded data in the hosting system for 
both near-real-time and archived data. 

• Manage all incoming PON traffic through bridges, routers, and gateways. 

The Processed Data Recorders (PDRs) are not part of the GOF but their operational 
activities are similar to the DBSs 1 . PDRs are used to perform the following functions: 

• Support recording of processed and unprocessed data simultaneously to 
Temporary Archive Media (TAM) and Permanent Archive Media (PAM); 

• Support retrievals from TAM; 

• From within a TRS 

• From authorized TRS external requesters - DBS, DP, or Payload Office 
Workstation (POW). 

• Support recording redundancy when configured as a Primary Recorder/Primary 
Retriever pair; 

• Support configuration and load for the TRS; 

• Provide high speed print capability. 
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The following assumptions apply to the operations of the PDRs and the GOF DBSs: 

• The PDRs and DBSs will be co-located in the same room to help minimize 
operations man power. 

• Data retrievals from a PDR are made from the TAM drives only. No PDR 
retrievals will be done from the PDR PAM drives. 

• PDR PAM disks will be moved and logged into the DBS catalog before the TAM 
overwrites the data. 7CMS operations makes the assumption that if the data is not 
on TAM, then it must be on the DBS and retrieval requests are routed accordingly 
by TCMS System Software. 

• The GOF operators will pre-ini tialize disks with a volume ID before a test 

TCMS O&M operators are responsible for operating both the DBSs and the PDRs. 

3.2.4. 1 Global Operations Facility / Processed Data Recorders Operational 

Components . The GOF consists of a number of components that will require operator 
intervention. Listed below are those components: 

• DBS 

• PAM storage system with at least 2 optical drives or optical jukebox(s) 

• 4 gigabyte magnetic hard disk 

• One SPF-compatible Software Distribution Peripheral (removable media) 

• Two 9-track tape drives 

• High speed laser printers) 

• Master Console DP 

• PON Router 

• PSCNI/C AD/CAE gateway 

• PDMS/POW gateway 

Each PDR consists of die following operational components: 

• 500 Megabyte hard disk 

• TAM hard disk storage 

• PAM storage system with at least 3 optical drives or optical jukebox(s) 

• One SPF-compatible Software Distribution Peripheral (removable media) 

• Magnetic tape drive 

• High speed line printer (shareable between PDRs) 

Consumables for GOF/PDR devices may include PAM cartridges, magnetic tapes, printer 
paper, and SPF-compatible distribution media. The KSC Supply System will provide all 
consumables required for GOF/PDR operations. A five day supply of consumables will be 
located in proximity to the GOF/PDR. 
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3.2A.2 Global Operations Facility / Proc essed Data Recorders Operations . TheGOF 
operators will be responsible for operations of the GOF DBSs, PDRs, gateways and 
printers, including replacing consumables, operator-level preventive maintenance, 
distributing printouts to the appropriate distribution box, and maintaining gateway 
configuration. Additionally, operators and communications personnel will main tain 
bridge, router, and gateway configurations. 

The GOF DBSs and PDRs will require the operators to maintain a media library and 
service user requests. A subset of the media library will be located in the GOF/PDR area 
containing a number of PAM media components. The main media library will be located 
in a room next to the GOF/PDR area in a controlled environment Access to this room 
will be limited to O&M and SR&QA personnel. The GOF operator must maintain these 
libraries so specific media can be found and mounted quickly. Each DBS will require 
media to be mounted and dismounted per user requests. 

In the current baseline, DBSs do not load share. Each user or group is assigned to one of 
die DBSs. This makes managing the requests more difficult and man power intensive since 
requests would have to be manually moved to the other DBS if necessary. PDRs will 
require new media to be mounted as current media is filled. It is the GOF operators 
responsibility to perform these functions. 

The DBS/PDRs will be co-located in the GOF area. This drives the need to display all 
PDR and DBS messages so that a few operators can monitor the messages and maintain 
knowledge of the status of all operations. The current baseline design is that messages are 
displayed at a terminal that is associated with each PDR or DBS and that the terminal 
monitors only the TRS in which it is configured. 

The baseline GOF configuration includes a single DP. The functions of this DP are as 
follows: 

• Provide a platform for network management for the GOF set equipment: 

• Provide a platform to receive retrieval related messages such as volume mount 
requests; 

• Provide a platform for manual entry into the DBS catalogs for logging disks into 
and out of the GOF. 

Each DBS and PDR has a dumb terminal attached to its console port The use of this 
terminal is restricted to O&M functions only, including: maintenance, operating system 
message acknowledgment and tape load requests. 

Current baseline dictates that PAM disks (rewritable opticals) arc recorded such that each 
side is considered a separate volume. The recording software is forced to record to 
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separate disks since the drives cannot record to both sides of the disk without the disk 
being flipped over. The TCMS baseline provides 3 disk drives per PDR that can be used 
in a round robin mode using all three drives (i.e., drive 1 -> 2 -> 3 -> 1...) or used in ping 
pong mode using only two drives (i.e., drive 1 -> 2 -> 1 -> 2...) to record. 

Note: ESR 99708 is outstanding to add jukeboxes to the PDRs and DBSs. If this ESR is 
approved, the PDRs will have two jukeboxes with one drive each. The recording will be 
in a ping pong mode between the drives. Flipping the disk over will not be necessary 
since the jukebox will do it as needed. 

Baseline provides that the Operations Engineer manually enters a volume id before each 
volume is initialized for recording. Automatic volume id generation is currently being 
investigated by the recording CSCL This volume id must also be manually affixed to the 
outside of the PAM for easy reading and cataloging. 

Preventive maintenance for the GOF/PDR is the responsibility of the TCMS O&M group 
and will be performed between tests and during third shift operations. Each DBS and 
PDR hard disk is required to be defragmented on a regular basis. Both the PAM and tape 
drives will be cleaned as part of preventive maintenance. The GOF Operations Engineer 
will perform these functions as well as maintain and monitor audit trail files of all 
GOF/PDR operations performed. 


3.2.5 DATA MANAGEMENT SYSTEM KITS. A DMS kit is an integrated set of 
electronic units and an interface device to connect these components to a host computer. 
DMS Kits will be provided in multi-phased stages as die development of the DMS 
hardware and software progress. 

DMS Kits are used for code verification and test support in place of the flight hardware. 
The DMS Kit requires a host computer that provides the simulation environment, control, 
and data recording and processing. 


3.2.5. 1 Data Management System Kit Operational Components . The configuration for 

individual DMS Kits will vary depending on the requirements and phase of testing or 
training. The configuration of DMS Kits for training and operational facilities will also 
vary depending on facility requirements and mission-specific configurations. The kit 
operational components are: 

• Simulation Interface Buffer (SIB) 

• Local Control Workstations (LCWS) 

• System Developmental and Diagnostic Subunit (SDDS) 

• Network Monitor Subunit (NMS) 
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• Network Simulator Subunit (NSS) 

• Functional Equivalent Units (FEUs) 

• Intermediate Rate Gateway (IRGW) 

• International Gateway (IGW) 

• Multiplexer Demultiplexer (MDM) 

• Ring Concentrator (RC) 

• Standard Data Processor (SDP) 

• Mass Storage Unit (MSU) 

• Multi-Purpose Application Console (MPAC) 

• Time Generation Subunit (TGS) 


3.2.5.2 Data Management System Kit Operations . TCMS O&M personnel are not 
currently responsible for the operation of the DMS Kits, their related components, or 
associated software. Responsibility for the operations of these items is currently under 
negotiation. 

O&M is responsible for the configuring, reconfiguring, preventive maintenance, and 
maintenance troubleshooting of DMS Kits. Maintenance is limited to troubleshooting and 
calling Work Package 2 for further assistance. 


3.2.6 COMMUNICATIONS AND PATCHING Communications and patching of 
TCMS hardware is covered in the TCMS Communications and Patching Plan, TS-TCMS- 
92004. For information on operations involved in the patching rooms, communications 
rooms, and other patching field areas, see the Communications and Patching Plan. 


3.2.7 USER ROOMS. The user's method of interfacing with an active set is 
primarily through a DP in one of the nine user control rooms. During testing, the Test 
Conductor is responsible for directing the test, test personnel, and monitoring all activity 
in the user room. Users who encounter any hardware or software problems will report 
them directly to the Test Conductor and/or Test Integration. With inputs from the test 
team, the Test Conductor will determine the severity of the problem. If a Problem 
Reporting and Corrective Action (PRACA) condition exists, the user will document the 
problem. The Test Conductor then forwards the users documentation to Quality so a 
PRACA report can be opened. The Test Conductor or Test Integration will then notify 
the sets MCOE . If a Test Conductor does not exist, users will notify the Client Support 
Area directly. 

User rooms are configured for individual tests by O&M personnel before test initiation 
according to Section 1 of the test's Operations and Maintenance Instruction (OMI). O&M 
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may remove user room wall partitions before test configuration is complete to form larger 
rooms. Sec Figure 3-2 and Figure 3-3 for the default user room configurations. 

Because a DP does not lend itself to unconstrained mobility, O&M policy is that DPs will 
not be moved. Moving wall partitions adjoining two rooms will effectively add DPs to a 
user area, thus satisfying user requirements for additional DPs in a TRS. 
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Typical TCMS User Room - Style A 
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Fig 3-3 

Typical TCMS User Room - Style B 


Hardware located in user rooms will be loaded with software and validated by TCMS 
O&M prior to test initiation. O&M will resolve any hardware or software anomalies that 
occur prior to test initiation. See Section 6, Anomaly Verification and Testing. 

3.2.7. 1 User Room Operatio nal Components . The user rooms consist of the following 

baseline operational components: 

• DP's 

• Laser Printers 

• Bridges 

• Repeaters 

• Co mm u n ications Servers (three of the nine user rooms) 


3.2.7.2 User Room Operations. User rooms contain at least one laser printer that will 
require paper and toner cartridges. Paper will be kept in proximity to the printers. It is 
the users responsibility to keep the local user room printers loaded with paper as needed. 
Toner will be replaced as needed, but a verbal request must be submitted to the Client 
Support Area for additional toner or paper. O&M personnel will check paper supply and 
toner availability during user room configuration to assure adequate supply is available. 

Preventive and corrective maintenance for user room equipment is the responsibility of the 
TCMS O&M group. Preventive maintenance will be scheduled between tests and 
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completed as a part of third shift operations. Corrective maintenance will be completed as 
needed. See Section 6, Anomaly Verification and Testing for more information. 

During tests, there may be vendor equipment located in the user rooms. This equipment is 
under the control of the vendor and will be maintained by that vendor in coordination with 
the TCMS MCOE. Section 1 of the tests OMI must account for the space necessary for 
the vendor equipment All required cabling of vendor equipment to KSC interfaces is the 
responsibility of the Payload Communications group. 


3.2.8 CARGO INTEGRATION TEST EQUIPMENT. Cargo Integration Test 
Equipment (CITE), if placed in the SSPF, will be operated and maintained as stated in the 
System Operations and Maintenance Manual for the Cargo Integration Test Equipment 


3.3 OPERATIONAL SERVICES 

Operational Services are those tasks that are beneficial to the users including: 

• TCMS Client Support Area (paragraph 3.3.1); 

• Payload Office Workstation Service Requests (paragraph 3.3.2); 

• Communications Requests (paragraph 3.3.3); 

• Set Peripheral Devices (paragraph 3.3.5). 

This section will describe those activities dealing with the TCMS Client Support Area and 
peripheral devices attached to TCMS equipment See Figure 3-1 for location of the 
TCMS Client Support Area. 


3.3.1 TCMS CLIENT SUPPORT AREA. The TCMS Client Support Area, which 
serves as the link between the users and O&M personnel, will be located in the Master 
Console Area of the TCMS Control Room. By collocating the Master Console and Client 
Support Area, response time will be minimal and will help provide synergy throughout 
TCMS. 

The Client Support Area is a subset of the Master Console and is positioned in the center 
of the master console horseshoes (see Figure 3-1). It consists of two POW class 
computers used for viewing anomaly information from the PRACA database. The Client 
Support Area is manned by TCMS MCOEs. Communications to and from the Client 
Support Area are through OIS-D. In cases where OIS-D is unavailable (such as off-site 
problems) telephone support is available. 
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The Client Support Area is strictly for reporting TCMS hardware and software 
breakdowns and requests. It does not include software operation questions. Users with 
application software operation questions will contact SSPSE. Problems with POWs are 
directed to the Network Services Help Desk. 

When a call is made to the Client Support Area, the sets MCOE will log the problem, and 
if possible, correct the it If an immediate solution can not be applied, the MCOE will 
contact the proper O&M personnel to correct the problem. For more information see the 
maintenance scenarios shown in Section 6, Anomaly Verification and Testing. 

The TCMS Client Support Area and the Network Services Help Desk will be working 
together to close IPRs, PRs and Trouble Tickets that affect POW hardware, software, and 
related components. The TCMS MCOE is responsible for tracking any anomaly that 
occurs on TCMS set equipment This includes active set equipment DMS Kits, DPs, 
TCMS bridges and routers, patch fields, and network cabling. Payload Office 
Workstations accessing TCMS data, their network equipment and network cabling are 
the responsibility of the Network Services Help Desk. 


3.3. 1.1 TCMS System Hardware / Software Anomaly Reporting . The TCMS Client 
Support Area will be the focal point for reporting, tracking, and managing the resolution 
of TCMS hardware/software anomalies. All calls will be logged and the appropriate 
organization^) notified. Client Support Area personnel will ensure the end user has been 
contacted to verify satisfactory resolution of the anomaly before writing the closure 
statement on the IPR or PR. 

Typically, only users on TCMS hardware (i.e., a display processor) will notify the TCMS 
Client Support Area. Users on POWs will contact the Network Services Help Desk with 
any problems that arise. Network Services will then turn the trouble ticket over to O&M 
if it's determined to be a TCMS problem. 

See Section 6, Anomaly Verification and Testing, for detailed information. 

3.3. 1.2 Network Services Help Desk. Network Services is currently responsible for 
hardware and software problems that arise on existing PC's. Since they currently have the 
expertise in this area, they will continue to function as the point of contact for TCMS 
POW anomalies. 

The Network Services Help Desk will be responsible for logging all calls that come from 
users working from a Payload Office Workstation. Users will call trouble tickets into the 
Network Services Help Desk. Network Services will then disposition the trouble ticket 
If it is determined to be a TCMS anomaly, it will be turned over to the TCMS Client 
Support Area. Otherwise, Network Services will correct the anomaly. 


3-17 


T5-TCMS-920Q2 
Rev Basic 
January 29, 1993 


Note: A Memorandum of Understanding is being developed between Network Services 
and TCMS that clearly defines the roles, responsibilities, and level of service. 


3.3.2 PAYLOAD OFFICE WORKSTATION SERVICE REQUESTS. The CSR 
will be used by TCMS users to obtain payload office workstation services. After the user 
fills out the CSR and submits it to the Network Services Help Desk, network services 
personnel will plan, implement and test the requested services. Once the work requested 
on die CSR is completed, network services documentation and configuration data will be 
updated by the appropriate department Network Services will then request data access 
from the TCMS System Administrator for the user submitting the CSR. Data access 
allows the user access to the TCMS GOF from a POW. 


3.3.3 COMMUNICATIONS REQUESTS. The CSR will be used by TCMS users 
to request communications-related services including printers, or POWs. All other TCMS 
communications are part of the tests OMI. An ESR must be written to include additional 
communication related requests in the OMI. The CSR will evoke the proper organizations 
to plan, coordinate, and develop a work package for the requested services. They will 
then be tasked to implement the work package. After the task is complete, documentation 
and configuration data will be updated to reflect the latest configuration. 


3.3.4 SET PERIPHERAL DEVICES. Set peripheral devices are operated by TCMS 
Operations personnel. These devices include printers, tape drives, disk drives, optical 
drives, and other such devices (DP floppy disk drives and printers are not included as they 
are operated by the user). The operator will be responsible for changing tapes, disks, 
cartridges, ribbons, toner, and keeping paper in the printers (excluding paper for printers 
located in the user rooms in which users will be responsible for keeping paper loaded) as 
well as distributing printouts to the appropriate distribution box located in the TCMS 
printer area. 

Media and paper will be supplied through die KSC Supply System and will be stored in 
proximity to the peripheral device. Used media will be stored in the media library in the 
SSPF. The media library is a separate, secured, climate-controlled storage area next to the 
TCMS Control Room, managed by TCMS O&M personnel. 


3.4 WORK TRACKING AND CONTROL 

Work Tracking and Control will be accomplished using applicable Technical Support 
Management Directives (TSMDs) and Standard Practices as well as the information found 
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in this document These documents address such topics as CSRs, IPRs, PRs, applications 
development and network outage coordination. 


3.4. 1 EVENTS. An event is a job or task that a user, operator, or group wishes to 
execute on a TCMS set Events may be scheduled or unscheduled with many falling in 
both categories. The following list includes many of the scheduled and unscheduled TCMS 
events: 


• Flight hardware testing; 

• Test Configuration; 

• File restoration; 

• Daily, weekly and monthly backups; 

• Line Replaceable Unit (LRU) replacement and off-line maintenance; 

• Simulation and Application development; 

• On-line and off-line maintenance; 

• Software load verification and validation; 

• Preventive and on-line maintenance; 

• Disaster recovery. 


O&M specific events will be scheduled through the TCMS System Administrator (see 
Section 8, System Administration). O&M specific unscheduled events will be handle on 
a priority basis. O&M event priority will be determined by the System Administrator in 
conjunction with TUG, users, and other O&M personnel. Upon event completion, any 
available results will be given to the event initiators) for review. 

The planning for these events will include support for OMI reviews, scheduling, pre/post 
test meetings. O&M personnel will support these activities as needed. 


3.4.2 SCHEDULED EVENTS. Scheduled events are those events that have been 
scheduled through the TCMS System Administrator prior to event execution. O&M 
events include: preventive maintenance, backups, scheduled LRU replacement All events, 
with exception of those described in paragraph 3.4.3 of this document will be scheduled. 
A priority may be attached to an O&M event by the System Administrator, TUG or other 
O&M personnel to prioritize event execution. Higher priority events may preempt lower 
priority events as system resources permit However, an initiated event will typically 
execute until completed before system resources are returned for use by pending events. 

The TCMS shift manager is responsible for ensuring all O&M events are scheduled and 
prioritized.. Once the O&M schedule is agreed upon, the shift manager will deliver the 
proposed schedule to the appropriate group for addition in the 1 1 day, 72 hour schedule. 
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3.4.3 UNSCHEDULED EVENTS. Unscheduled events are those events that have 
not been previously scheduled and are deemed critical to TCMS operations. By nature, 
these events, consisting of emergency operations, have a higher priority and may preempt 
a scheduled event 

Unscheduled events include such events as file restoration, disaster recovery, LRU 
replacement and verification, subsystem or test article trouble shooting, and resolving 
network cabling problems. Unscheduled events do not include preventive maintenance, 
subsystem validation or related events that should be scheduled. 


3.4.4 SHIFT OPERATIONS. The TCMS O&M work day is divided into two or 
three shifts with one or two additional shifts overlapping the two or three standard shifts. 

First shift operations will be 07:00 - 15:30, Second shift operations will be 15:00 - 23:30, 
and third shift operations will be 23:00 - 07:30. In addition there may be an overlapping 
shift which will start after the normal start of the first shift and continue after the start of 
second shift. See Figure 3-4 below. 

All times listed in the figure below are preliminary and may change after TCMS activation. 
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Fig 3-4 

Shift Operation Schedule 


3*4.4. 1 First and Second Shift First and second shift operational activities include: 

• Monitoring system activity on all half sets 

• Monitoring health and status of all half sets 

• Responding to user inquires 

• Error detection 

• Support of active tests 

• Support of simulation and test application software verification 

• Set configuration 

• Printout distribution 

• Corrective maintenance 

The major function of the first and second shifts will be to support active tests and 
configure available set resources for scheduled use. 
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3.4.4.2 Third Shift Third shift operations include: 

• First and second shift operations should testing be scheduled 

• Corrective maintenance 

• Backup of system resources 

• Verifying integrity seals 

• System tuning 

• Upgrade installation 

• General subsystem file maintenance 

• Preventive maintenance including: 

• Diagnostics 

• Cleaning 

• Changing filters 

• Implementing planned LRU replacement (scheduled maintenance) 

• Network signal flow validation 

• Software load verification 

The major function of the third shift is to perform those events that bring the sets integrity 
level to the highest possible level. Third shift operations include those supporting events 
that are required to provide reliable operation of TCMS. 

Third shift operations may also include all the activities associated with first and second 
shift operations. At times there may be flight hardware tests and set configuration 
scheduled for third shift 

Backup of system resources will take place during third shift A subset of the media 
library exists off-site where the storage of disaster recovery backups will be maintained. 
The third shift Operations Engineer is responsible for performing the backups and 
maintaining the off-site media library. 


3.5 OPERATIONS AT CORE ELECTRONICS CONTRACTOR SITE 

If operations at the Core Electronics Contractor site are required, they will be similar to 
operations at KSC. See Section 3 for additional information. 


3.6 CENTRAL SOFTWARE FACILITY / CENTRAL AVIONICS FACILITY 
OPERATIONS AT JOHNSON SPACE CENTER 

Operations for the Central Software Facility/Central Avionics Facility (CSF/CAF) at 
Johnson Space Center (JSC) will be similar to operations at KSC. 
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SECTION IV 

RESOURCE MANAGEMENT 

4. 1 HARDWARE RESOURCES 

This section includes a listing of all the Hardware Configuration Items (HWCI) in TCMS 
followed by a brief description of each item. Also included are descriptions of the more 
important specialized pieces of test equipment unique to the TCMS system. 


4.1.1 DISPLAY PROCESSOR. The DP is the system interface to the user within 
the Core distributed architecture. In simple terms, it is where the user does the testing. 
The DP has a 32-bit CPU, a keyboard, a pointing device, a primary display, up to three (3) 
slave monitors, a removable media device, and an MS DOS compatible floppy drive. The 
DPs directly interface with the Display Network Subsystems (DNS) for accessing the 
Applications Processor (AP), data storage and retrieval subsystem, DBS, service network, 
SPF, and external systems such as PDMS. 


4.1.2 APPLICATION PROCESSOR. The AP is a UNIX-based processing node 
within the Core distributed architecture. It is a computation-intensive subsystem that 
primarily executes real-time system services and test application programs. It consists of 
two 32-bit CPUs, a hard drive, and a removable media device. It interfaces directly with 
the DNS for access to the DPs and through a Buffer Input/Output Processor (BIOP) to 
the Real Tune Network (RTN). It also interfaces directly with the Service Net (SN). 


4.1.3 FRONT END PROCESSOR. The Front End Processor (FEP) is a universal 
hardware element that performs the protocol and data processing necessary to support a 
wide variety of synchronous and asynchronous test article control and data acquisition at 
the front end interfaces. It consists of several CPUs and interface modules housed in a 
Versa Module Eurocard (VME) bus chassis. The specific interfaces required govern the 
configuration of this chassis. The FEP can process all known space station, payload and 
ground support equipment data types by configuration of interface cards, custom software 
and customized high performance filter modules. The FEP communicates to the other 
subsystems by way of the RTN through a BIOP. It also interfaces directly with the SN 
(release 2 functionality). 


4.1.4 REAL TIME NETWORK. The Real Time Network (RTN) provides message 
and data communication capability for attached processors. The RTN utilizes star 
topology with hosts connected to the central node through dedicated, high speed, point- 
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to-point links. Through access control of shared data storage area and message routing 
tables, the hosts attached to the RTN can be configured into multiple Test Resource Sets 
(TRSs) to support parallel operations. The RTN consists of the Common Data Buffer 
(CDBFR), host resident BIOPs, and host resident Monitor Input/Output Processors 
(MIOPs). The BIOP supports the exchange of single, multiboard and homogenous data 
sets as well as messages. Error detection and correction and/or error reporting 
mechanisms ensure the integrity of the information. The MIOP is a unidirectional link that 
routes data passing through the RTN to a PDR. It also interfaces directly with the SN. 


4.1.5 HARDWARE INTERFACE MODULE. The Hardware Interface Module 
(HIM) acts as the front-end element of TCMS and is connected to the GSE data bus for 
communications with the FEP. A FEP may control up to eight HIMs through a ground 
data bus. The modular design of the HIM accommodates several types of interfaces 
depending upon the particular configuration required. There are two basic types of HIMs; 
the slave HIM and the standalone HIM. The slave HIM is always connected to a FEP and 
its' function is to either transfer measurement data from a GSE device to the FEP, or to 
pass a command from the FEP to the specific GSE device. Thus, there is no algorithmic 
processing of measurements or command generation in the slave HIM. The standalone 
HIM interfaces to GSE equipment as in a slave HIM, but gathers measurements and issues 
GSE commands without requiring a FEP. 


4.1.6 PROCESSED DATA RECORDER. The PDR records data from the RTN to 
support near real-time retrievals and post-test retrievals. The data consists predominantly 
of preprocessed test article data from a FEP. The PDR records on two different media 
simultaneously. TAM supports the near real-time retrievals and PAM supports a historical 
record. The PDR interfaces with the RTN for data recording and the DBS for the 
retrieval functions. It also interfaces directly with the SN. 


4.1.7 DATABASE SUBSYSTEM. The DBS provides the data management and 
data handling functions to support the data display and analysis performed during and after 
tests. The DBS supports data retrieval and analysis. During a test the DBS supports data 
retrieval and analysis of the PDR recorded data. 


4.1.8 DATA MANAGEMENT SYSTEM. The DMS kit typically contains a SIB 
and a set of Functional Equivalent Units (FEUs, which can be described as non-flight 
versions of various space station components). The SIB is the interface device within the 
DMS kit that provides the interface bridge to the Space Station Freedom environment, 
including the local buses and networks. Each SIB is composed of a local control 
workstation and a number of subunits that may or may not include all the following; a 
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Local Bus Input/Output Subunit (LIOS) for SN/0 only, a Multiplcxcr/Demultiplexer 
Interface Subunit (MIS), an SDDS, an NSS, and an NMS. The space station DMS buses 
and networks include MIL-1553B local buses, ANSI X3T9.5/83-15FDDI networks, and 
an EIA RS-422A time distribution bus. 


4.1.9 SOFTWARE PRODUCTION FACILITY. The SPF is the hardware set used for 
development and configuration management of applications and simulation software. SPF 
allows software developers to perform final compiles on the target subsystems. It serves 
as a local repository for downloaded MODB data, build data, and test configuration 
functions. Several databases are also located on the SPF. 


4.1.10 SPECIALIZED TEST EQUIPMENT. 

4.1.10.1 Functional Interface Test Tool . The Functional Interface Tool (FIT) is a 
portable device that is designed to perform card level testing of the custom Input/Output 
(I/O) cards in the HIM. The FITs FEP Simulator function is able to simulate, record, 
and verify the HIM’s responses to roll calls, FEP commands/queries, and I/O card 
transactions. The FIT consists of a keyboard, monitor, CPU, and floppy drive, all 
contained in a hand-carried housing. 


4.1.10.2 HP3Q70 Board Tester . This is a highly computerized device that is capable of 
checking both the functionality and operational readiness of custom designed circuit 
boards. The board tester is able to verify functionality and operational readiness with 
board-unique templates that this device can fabricate for each custom circuit board. 

4.1.10.3 RTN Analyzer . The RTN analyzer is a tool formonitoring the activity through 
the RTN. It consists mostly of custom LRUs such as the Input/Output Processors that are 
identical to those used in the RTN. One custom card, the Link Tester, is unique to the 
RTN analyzer. 


4.1.10.4 Configuration. Calibration, and Test Set The Configuration, Calibration, and 
Test Set (CC ATS) provides the capability to verify data transmission throughout the Core 
system. When integrated with the Core system, CCATS can be used in the configuration, 
calibration, and testing of a TRS or elements within a TRS. CCATS can also be used in a 
stand-alone mode to verify the electrical characteristics of Core subsystem interfaces. 
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4.2 SOFTWARE RESOURCES 

This section includes a listing of all the Software Configuration Items (CSCI) in TCMS 
followed by a brief description of each item. 


4.2.1 SYSTEM SOFTWARE. System Software is a collection of custom designed 
software programs called Computer Software Configuration Items(CSCIs) that are being 
developed by the CEC. These CSCIs work in conjunction to provide the software 
functionality required for TCMS. A detailed description of each CSCI is given below: 


4.2. 1.1 Test Build . Test Build (BLD) provides the capability to create and edit a Test 
Configuration for test of a Test End Item. BLD provides the initial identification of the 
Test Configuration; creation of the Function Designator Directory (FDD), creation of FEP 
Tables; creation of Remote Interface Tables for HOSC, Real Time Interface (RTIF), and 
CCP; creation of Central Data Subsystem (CDS) Build Products; and creation of Test 
Configuration Partitions. An Online Data Bank (OLDB) is created when a request is 
received from the Configure Tests (CTS) CSCI for transfer of a Test Configuration. 

Some operations may be executed concurrently. Creation of the Test Configuration is 
initiated by a client through the Human Computer Interface (HCI) Test Development 
Services (HTD) CSCL 


4.2. 1.2 Commercial Development Environment Commercial Development 

Environment (CDE) provides the development environment for Test Application Software 
in the commercial High Order Languages. This environment includes a Commercial-off- 
the-shelf (COTS) syntax-directed editor, compiler, linker, and static analyzer. A custom 
precompiler is provided to perform Function Designator (FD) reference checks. It also 
provides the environment for expert system development 


4.2. 1.3 Command Processing . Command Processing (CMP) is responsible for the 

validation and issuance of client entered and test application software generated 
commands. Command validation includes command parsing along with checks for syntax, 
client permissions, command applicability, prerequisite sequence, and two-step command 
processing. Command issuance includes monitoring Test End Item commands for 
completion status from front end processors and routing validated commands to 
applications within the TRS. This CSCI is also responsible for the initiation of all transient 
routines requested by the client or test application software. 
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4.2. 1.4 Configuration Manag ement Services . Configuration Management Services 

(CMS) performs four basic Configuration Management (CM) Service functions: 
configuration control, revision tracking, transaction logging, and status accounting, which 
arc distributed through the Develop Tests CSCIs and accessed by the HTD CSCL 


4.2.1.5 Configure Test CTS provides the capabilities to establish a TRS by defining 
die software loads, interfacing with System Management (SMG) to provide CDBFR-II 
configuration data, receiving the System and Test Configuration software loads from the 
SPF or transferring from the GOF to the Test Resource Set local storage, and distributing 
the software to the Hardware Resources within the TRS. 


4.2. 1.6 Data Acquisition and Control . Data Acquisition and Control (D AC) is 

responsible for the acquisition, processing, and exception checking of data from the Test 
End Item. This CSCI provides a command interface between Core and the Test End 
Item. 


4.2. 1.7 Data Storage Management Data Storage Management (DSM) stores data on 
various types of physical storage media, in many different data formats. The data is under 
the control of several different database or file management systems. The DSM CSCI 
provides higher-level Core CSCIs with access to this stored data, independent of the 
location or the characteristics of the physical storage media. 

This service provides low-level data administration functions for the Core stored data. It 
includes services necessary to manage, administer, monitor, protect, modify, and main tain 
integrity of the stored information. Custom software solutions arc only implemented when 
COTS products do not fulfill the Core requirements. This service also maintains the 
integrity and consistency of data replicated across platform boundaries. 


4-2, 1.8 Ground Operations Aer ospace Language/Control Logic/Test Control 

Supervisor Development Environment Ground Operations Aerospace Language/Control 
Logic/Test Control Supervisor Development Environment (GCE) provides the 
development environment of Test Application Software using GOAL, CL, and TCS. This 
environment includes a syntax directed editor, syntax checker, compiler, and static 
analyzer. The capabilities supporting GOAL and CL development are generic capabilities 
provided for both CCMS-II and TCMS. The capabilities supporting TCS development is 
specific to CCMS-IL 
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4.2. 1.9 Human Computer Interface Real Time Services . Human Computer Interface 
Real Time Services (HRT) provides interactive displays that allow clients to perform, 
monitor, and control activities, perform test support functions, and specify data retrieval 
report requests. This CSCI allows clients to control and monitor Test End Items, safing 
capabilities, and data retrieval and analysis capabilities. 

Additionally, HRT provides client interaction displays that allow clients to transfer the 
build configuration, configure resources, load and initialize the TRS, interface with the 
timer services, control recording of test data, interface with health and status, and 
maintenance functions. 


4.2.1.10 Human Computer Interface Support Environment Human Computer Interface 
Support Environment (HSE) provides the basic input/output facilities between the HCI 
Real Time Services CSCI, HCI Test Development Services CSCI, the Workstation HCI 
and the Display Processor. The HSE CSCI is composed mainly of COTS software 
products with a minimal amount of custom software where required to provide the 
necessary access to functions and transparency layer. It provides windowing and window 
management functions with a Direct Manipulation Interface (DMI) environment It also 
provides facilities for executing Core system defined displays, editing and executing 
Display Graphics, accessing Programmable Function Panels (CCMS-II only), formatting 
and providing analysis requests to a COTS graphing product for retrieved archived data 
reports, and special functionality as required for interacting with external interface 
displays. 


4.2.1.11 Human Computer Interface Test Development Services . HID allows clients 
to manage test article and link definition data, develop Test Application Software, define 
and manage test configurations, manage Core resources, manage client account 
information, and customize and manage client interfaces to suit individual or group needs. 

The HTD CSCI also provides access to COTS products (Syntax Directed Editors, 
Graphical Editors, compilers, linkers, debuggers, DBMSs). Once a session is established 
with any of these COTS products, the client interface is provided to the initiated COTS 
product Additionally, the HTD CSCI provides the actual client interfaces for those areas 
where the use of COTS may not be suitable and where the functionality will be provided 
by Core-developed software. 

Lastly, the HTD CSCI uses report data generated by other support CSCIs and routes this 
report data to the appropriate client selected output destination (display, soft copy, or 
printer). This CSCI provides access to Test Development functions residing in the SPF 
Hosts. The Test Development functions are accessible from a DP or POW compatible 
workstations. 
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4.2.1.12 Link Configuration Database Manager . Link Configuration Database 
Manager (LDM) provides the capability to incorporate, edit, administer, and report Link 
Configuration Data contained in the Link Configuration Database. A client is allowed to 
interactively examine the Link Configuration. 


4.2.1.13 Monitor Data for Distribution . Monitor Data for Distribution (MDD) provides 
the distribution of real time data to external systems and is responsible for Exception 
Monitor (EMON) processing. Display Monitoring (DMON), Predictive Trending 
processing. Dynamic Display processing, and for TCMS, POW processing of FD data. 

For CCMS-H, the MDD function is responsible for the gathering, formatting, and 
transmission of real time data to the KSC CDS through the RTTF IF and for responding to 
commands to plot on die SCRS real time and recorded data. 


4.2.1.14 Network Manager . NMG performs three basic functions: configuration, 
where devices are controlled; monitoring, where management information is retrieved and 
stored; and reporting, where abnormal events concerning network devices are reported. 
The NMG is primarily COTS. 


4.2.1.15 Record Test Data . Record Test Data (RCD) performs real time recording of 
Test End Item Data and Test Resource Set Data. This recorded data is used by the 
Retrieve and Format Test Data (RFD) CSCI for the purpose of retrievals during or after 
test execution. On the PDR, unprocessed data consists of Test End Item (TEI) data that 
has been extracted from the data stream and identified by the FEPs but has not been 
linearized or converted to engineering units. Processed data consists of TEI data that has 
been fully processed by the FEPs and placed into the CDBFR. On the Digital Record and 
Retrieval Subsystem (DRRS), raw data is recorded directly from the buses before it is 
decommutated by the FEPs. 


4.2.1.16 Retrieve a nd Format Test Data . RFD performs retrievals of raw TEI data 
(CCMS-H), processed TEI data and Core internal data. The retrieved data is formatted 
for retrieval reports and CDS backfills. Management of retrieval control requests is also 
provided so that a client with proper permissions or test application software may cancel, 
suspend, or resume retrieval requests. A client with proper permissions may 
activate/inhibit near-real-time and post test retrievals. The client or test application 
software may also request a status of all retrievals. 
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4.2.1.17 Resource Manager . Resource Manager (RMG) provides the capability to 
define hardware resources, allocate hardware resources to TRSs, and maintain an 
accounting of their use. This CSCI is responsible for maintaining the Hardware Resource 
Database through client interaction. It also assists the client in allocating resources to a 
particular test, and subsequently modifying that allocation in response to a hardware or 
software problem. 


4.2.1.18 System Management SMG is responsible for controlling and monitoring 
resources within a set, which includes shared resources, resources allocated to an 
operational TRS configured to support a test, and resources allocated to a default TRS. 
This CSCI is also responsible for the current configuration and status of all resources 
within the set 


4.2. 1.19 SPF Manager . SPF Manager (SPM) provides tools for project management, 
requirements and design analysis, SR&QA and Independent Verification and Validation 
(IV&V). 


4,2.1.20 System Software Services . System Software Services (SSS) is divided into 
four distinct groups. These groups are operating system environment, operating system 
transparency, distributed environment transparency and general software services. 

The SSS CSCI provides services such as: interprocess communication, file/library 
management, process control, resource management, system wide messaging capability, 
engineering units conversions, and time conversions. 


4.2.1.21 System Op erational Readiness Testing . System Operational Readiness Testing 
(SYM) provides the client with the capabilities of supporting fault detection, fault isolation 
and trouble shooting initiated from the TRS level. System Operational Readiness Test 
(ORT) invokes TRS ORT, which tests the communication paths of the configured 
hardware resources. Each physical data link, hardware unit and peripheral will be tested 
to verify that the TRS is capable of supporting a test configuration. 


4.2.1.22 Test Application Execution . Test Application Execution (TAE) is responsible 
for the execution of Test Application Software that is composed of Core Custom 
Language Programs and Commercial High Order Language Programs. The TAE CSCI 
provides the interpreter for GOAL and Control Logic language programs. The TAE 
CSCI, through the use of the Command Processing CSCI, issues and executes commands 
contained in Test Application Software (TAS) Programs to the Test End Item and the 
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Test Resource Set TAE provides application generated data to the HCI real Time 
Services CSCI for display to the client 


4.2.1.23 Test. Contro l and Monitor System Bulk Input. TCMS Bulk Input (TBI) 
provides the capability to receive and process Test End Item and Link Configuration data 
transmitted from the responsible design agency at JSC. 


4.2.1.24 Test End Ite m Data Bank Manager . Test End Item Data Bank Manager 
(TDM) provides the capability to create and update commands used to modify Test End 
Item and System Validation data in the Data Bank. The update commands can originate 
from either CBI or TBI or a workstation. In addition, the TDM CSCI provides the 
capability to generate a copy of the Data Bank and to produce numerous pre-defined 
reports of the data contained in the Data Bank. 


4.2.1.25 Test End Item Software Manager . Test End Item Software Manager (TSM) 
provides services to manage data from Shuttle on-board processing received from JSC. 
This includes on-board load, dump, and compare. 


4.2.1.26 Configuration and C alibration And Test Set CCATS provides the capability 
to verify data and command transmission paths from a DP to a FEP in the Core System. 
It captures and analyzes interface data to isolate a problem to a subsystem or group of 
subsystems with a TRS. 


4.2.2 COMMERCIAL-OFF-THE-SHELF SOFTWARE. COTS software is 
software that has not been specially designed for TCMS. This software is commercially 
available and therefore saves resources. 


4.2.2. 1 Operating Systems . An operating system (OS) coordinates the multitude of 
activities going on within a computer. At all times, an operating system must ensure that 
characters arc correctly displayed on the screen, that data is saved and retrieved without 
error, that instructions are processed in an orderly way, and that you are informed if an 
error occurs. An operating system is a coordinator whose function is to keep all parts of 
the system functioning smoothly and in harmony. 


The OS for the VAX computer system located in the SPF is VMS from Digital Equipment 
Corporation. The APs will use CX/UX OS from Harris Corporation and the DPs will use 
ULTRIX OS from Digital Equipment Corporation. The FEPs will run on V ADS works 
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OS from Verdix corporation as will the Standalone HIMs. The Slave HIMs will run on a 
VX- Works OS kernel from Wind River Systems, Inc. 


4.2.2.2 Compilers . Compilers are tools that allow easier programming for the 
software developer. They allow the developer to write code in a High Order Language 
(HOL) that is more readable by a human, and convert this 'code' to a machine language 
executable file that the computer will understand. Compilers help to bridge the gap 
between what the computer understands and what the developers/programmers 
understand. 

For TOMS, the following HOL compilers will be made available: 

• C 

• Ada 

• GOAL 


4.2.2.3 Su pport Software . Support Software is software that supports the OS. Some 
examples would be VAX 6000 diagnostic set, VAX Cluster Software, DECNET 
Software, VMS Volume Shadowing, Artemis 7000, etc. 


4.3 HARDWARE AND SOFTWARE RESOURCE MANAGEMENT 

4.3.1 CENTRAL AVIONICS FACILITY. While the methods of conducting testing 
in the Central Avionics Facility at the Johnson Space Center in Houston, Texas are 
currently at the Preliminary Design Review stage and therefore somewhat vague, it is 
anticipated that the hardware scheduling and allocation will be accomplished in a manner 
similar to that described in the following paragraphs. 

4.3.2 HARDWARE SCHEDULING/ALLOCATION. The scheduling and 
allocation of the TCMS hardware is accomplished through the eleven day/seventy-two 
hour schedule. The user community provides the initial requirements for hardware into 
this schedule. The user community then develops OMIs from the eleven day/seventy-two 
hour schedule. The O&M group refers to Section 1 of a given OMI for the specific 
equipment required for a particular test The O&M group then matches individual 
resources with individual requirements and provides functional resources at the required 
time for die duration of the test Additional planning will be required if the Section 1 
identified equipment exceeds the equipment allocated to that set 
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4.3.2. 1 Operational Sets. To be assured of timely TCMS O&M support of formal 
Space Station testing, appropriate time periods will be need to allow reconfiguration and 
patching of the TCMS set of interest, as well as an understood method of identifying the 
equipment required and/or modifying the equipment required for the TCMS set of interest 

As for the time periods required, the users shall be able to provide a detailed listing of the 
TCMS equipment required to support a given test in the form of Section 1 of an OMI at 
least five days before the start of a formal test 

In the event of modifications to the original OMI equipment listing by the users 
immediately before the start of a test or during an actual test the TCMS O&M group will 
give immediate attention to the modification, and the users can expect an additional delay 
due to reconfiguring/repatching of no more than twenty-four hours. 

It has been agreed that the user community will have the responsibility to avoid potential 
TCMS equipment conflicts and to resolve them when they occur. Should an equipment 
conflict go undetected by the users, the TCMS O&M group will, upon discovery, 
immediately notify the appropriate users of the conflict and participate in the resolution of 
the conflict as required. 


4.3.2.2 Development Set To facilitate speedy development of Space Station test 
software, the users and the O&M group have a much closer and less formal working 
relationship when working with TCMS equipment designated as development set 
equipment 

Before the start of each shift where equipment change/reconfigure/repatch is required, an 
authorized user will provide the O&M group with a listing of the equipment required, 
along with an estimate of how long the equipment will be required for development 
purposes. The TCMS O&M group will then provide the authorized user with an estimate 
of the time required to make the appropriate changes. With the understanding that 
support of a formal test is the primary TCMS O&M responsibility, the O&M group will 
immediately begin the requested changes. 


4.3.3 HARDWARE MANAGEMENT. The configuration management system will 
be used for tracking tire current configuration of, providing for the assured integrity of, 
and introducing approved changes to, the TCMS hardware, not including test equipment 

The configuration management system identifies the hardware items to be placed under 
configuration control and describe their baseline configuration. The Payload Level m/IV 
CCB addresses proposed changes to the configuration baseline. Verification of changes is 
accomplished by reviews to assure that hardware design satisfies approved requirements 
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and that modifications have been incorporated per the modification instructions. 
Configuration accounting is accomplished by an automated configuration management 
tracking system that provides visibility of all changes to the current baseline. 


4.3.3. 1 Configuration Identification for TCMS Hardware . Configuration identification 
is the process of selecting hardware items to be under configuration control, describing 
their baseline configuration in terms of technical documentation and hardware identifiers, 
and the system for preparing, maintaining, and releasing configuration documentation. 

The functions of configuration identification are described in the following paragraphs. 


4.3.3. 1.1 Identification of TCMS Hardware Un der Configuration Control . TCMS 
hardware items to be under configuration control are established by NASA and accepted 
by die PGOC during transition. The PGOC authorization to add or delete TCMS 
hardware items to/from the accepted baseline is by Configuration Control Board Directive 
(CCBD) and/or Contract Change Order (CO). The PGOC Program Control - 
Configuration Management department will maintain a current listing of items under 
formal program/project configuration control. 


4.3.3. 1.2 Baseline Identificatio n for TCMS Ground Hardware . The configuration 
baseline is the current defined and approved configuration used as a reference point for 
program/project planning purposes and as a point of departure for control of changes. 
The baseline identification and all approved changes thereto are maintained by the PGOC 
Configuration Management Organization. 


4.3.3. 1.3 Engineering Documentation Preparation. Maintenance. Records, and Release 
System . The PGOC will use or adapt existing methods and systems for the preparation, 
maintenance, record keeping and release of engineering documentation. Existing syste ms 
will be used except when system changes will require NASA approval before 
implementation, e.g., if changes affect non-PGOC. 


4.3.4 SOFTWARE MANAGEMENT. The details of how TCMS system and 
application software will be managed and controlled can be found in the TCMS 
Production Control Plan, K-CTE-63.2. The TCMS system and applications software of 
interest includes both COTS and custom designed software. Items such as how the 
current system software configuration will be tracked, how the integrity of the system 
software is guaranteed, how approved changes are introduced, and where correct copies 
of system software arc stored will be found in the TCMS Production Control Plan. 
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4.4 DOCUMENTATION MANAGEMENT 

Procedures, separate from this document, will be written by O&M to detail documentation 
management 
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SECTION V 

PERFORMANCE MANAGEMENT 


Overall TCMS performance will be managed by TCMS O&M. This organization is 
responsible for ensuring that TCMS performance goals and objectives are satisfied. A 
working group will address the following disciplines: communications, systems, and 
software. The working group consisting of O&M, Payload Coram, SSPSE, SPA, and 
SR&QA will develop measurements and standards based on justifiable user requirements, 
analyze the results of performance measurements, industry trends, and evaluate proposed 
modifications to meet performance objectives. 


5.1 SYSTEM PERFORMANCE 

A major function of TCMS O&M will be to fine tune the systems performance and 
reliability. This will be accomplished by: 

• Design and fine-tuning a system configuration that best meets the demand for 
computer resources; 

• Monitoring system resources (memory, CPU, disk I/O, network I/O, etc.) 
using TCMS-provided tools; 

• Using historical and statistical methods to plan future growth; 

• Providing/receiving technical assistance and guidance to/from the database and 
applications developers to ensure system resources are used effectively; 

• Working with the database designers and applications developers to ensure 
performance and resource considerations are understood and followed; 

• Planning, installing, configuring, and verifying system hardware and software 
to maintain system integrity; 

• TUG will meet to finalize initial system design and delivery. TUG will 
continue to meet regularly to analyze the configuration's impact on overall 
performance, recommend changes, and plan future upgrades. 
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5.2 NETWORK PERFORMANCE 

Network management tools provide the ability to monitor traffic and status. Network 
performance measurement will be implemented using procedures developed jointly by 
TCMS O&M and PGOC Communications groups. These procedures address network- 
related performance measurements and those required for network maintenance. 


5.3 SOFTWARE APPLICATION & DATABASE PERFORMANCE 

Application and database performance will be measured and tuned in a cooperative 
manner between users and O&M to maximize the performance of scarce TCMS resources. 
Hardware and software development tools will be used to optimize performance features. 


5.4 PAYLOAD OFFICE WORKSTATION PERFORMANCE 

The impact of TCMS design and software on workstation performance will be assessed by 
the Network Services Department 


5-2 


TS-TCMS-92002 
Rev Basic 
January 29, 1993 


SECTION VI 

ANOMALY VERIFICATION AND TESTING 

TCMS hardware and system software will be tested through CEC acceptance testing. 
Joint DL/CS activation/validation testing will also be executed on each TCMS set as it is 
delivered and on major hardware deliveries. These formal tests are conducted to assure 
that all TCMS equipment meets the specified system requirements defined in the TCMS 
Facility Equipment Requirements Document/Design Plan (FERD/FEDP), KSC-STA- 
61.07. These tests include performance demonstrations and environmental exposures that 
have been completed before O&M assumes responsibility for the hardware or software. 
Specific information on the integrated activation/validation process can be found in the 
TCMS Activation/Validation Management Plan, KSCM-DL-01 12. 

Once the system is accepted by NASA, the TCMS O&M group will ensure its operational 
integrity through health & status, system & subsystem ORT and diagnostics. This 
includes the preventive and corrective maintenance of all TCMS-related hardware, system 
software, and the LRU removal & replacement as described in TCMS Main te nan ce Plan, 
TS-TCMS-92003. 


6. 1 ERROR DETECTION AND PROBLEM RESOLUTION 

Error detection and problem resolution involve three O&M groups: operators, hardware 
maintenance, and software maintenance personnel Hardware and software main tenance 
personnel will be involved with problem resolution of only those anomalies that involve 
their specific areas. The user community will be involved in supporting problem 
resolution. Throughout the resolution process current configuration control procedures 
will be followed to insure system configuration. 

When an anomaly occurs, and the sets MCOE is notified through the Master Console 
health and status function or by user notification through OIS-D, if necessary, the MCOE 
will try to determine the type of anomaly (i.e., hardware or software) and, if possible, on 
which platform the anomaly is occurring. The MCOE will gather as much information as 
possible on the anomaly characteristics. After determining the type and gathering the 
characteristic data, the MCOE will document the problem, contact quality to open an IPR 
and contact the appropriate maintenance personnel to correct the anomaly and present 
them with the collected data. 

The PRACA system will be used to insure all problem resolution actions are tracked 
before returning the set to its on-line state. The appropriate maintenance engineer 
together with the quality representative will escalate the IPR to a PR for toubleshooting 
and maintenance. Once the problem is corrected, the appropriate maintenance engineer. 
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NASA counterpart, and quality representative will close the PRACA report For 
information on PRACA, see Nonconformance/Problem Reporting and Corrective 
(PRACA) System, SP10.001. 


6.1.1 ASSUMPTIONS. The following paragraphs include assumptions for the 
typical TCMS maintenance process. Assumptions are dependent on the location of the 
user. Each paragraph shows the set of assumptions for that location. Hie four figures 
following the assumptions apply for all locations and depict the maintenance process once 
TCMS has been determined to house the anomaly. Figure 6-2 shows the overall TCMS 
organizational maintenance flow. Figure 6-3 shows the flow for system hardware 
maintenance, Figure 6-4 shows the LRU repair flow, and Figure 6-5 shows the software 
maintenance flow. 

The box in figure 6-4 marked "Special Hardware Dispositioning" represents the actions 
taken as the result of recurring failures. Each time an LRU is processed through the Off- 
line Support Area (OS A), failure data will be entered into the Production Tracking System 
(PTS). When the OS A cannot find a problem with an LRU sent to the OSA, the PTS will 
be used to determine if the problem is recurring. It is anticipated that the quantity of this 
type of failure will be limited and each will be handled on a case-by-case basis. For 
recurring problems, TCMS O&M personnel have several options depending on the 
circumstances. 

1. If the problem is not an isolated case (i.e., it appears to be a design 
problem), TCMS O&M will work with the CEC or TCMS Sustaining 
Engineering to ensure that the problem is properly resolved. 

2. TCMS O&M may elect to return the LRU, through TCMS Logistics, to 
die appropriate repair facility and work with that repair facility to ensure 
the problem is corrected. 

3. TCMS O&M may elect to perform in depth troubleshooting in the OSA to 
duplicate and isolate the problem. 

4. TCMS O&M may elect to have the LRU scrapped through the Material 
Review Center (MRC). 

Figure 6-5 contains a box marked "Special Software Dispositioning" that represents the 
actions taken when a software problem cannot be duplicated. In such cases, TCMS O&M 
Software Engineering will work with the CEC, TCMS Sustaining Engineering, SSPSE, or 
the COTS software vendor as appropriate to isolate and resolve the difficulty. 

For specific information on maintenance, see the TCMS Maintenance Plan, TS-TCMS- 
92003. 
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6.1.1. 1 Payload Office Work station Assumptions . Hie following assumptions apply if 
the user calling in the Trouble Ticket is working from a POW. A POW is defined as either 
an IBM compatible computer or an Apollo workstation connected to TCMS through the 
PON. 


• Users working on POWs will call Trouble Tickets into the Network Services Help 
Desk. POW users will not contact the TCMS Client Support Area. 

• If it's determined to be a TCMS anomaly. Network Services will close out the 
Trouble Ticket and immediately transfer the information on the anomaly to the 
TCMS Client Support Area where an IPR will be opened for further 
troubleshooting. Troubleshooting may include contacting the user for help in 
expediting the problem resolution. 

• If it's determined not to be a TCMS issue. Network Services will correct the 
anomaly. 


6.1. 1.2 Display P rocessor Assumptions . The following assumptions apply if the user 

calling in the IPR is working from a DP. 

• Active Test DPs 

• Users working on DPs will notify the Test Conductor and/or Test Integration 
who will notify the TCMS MCOE through an OIS-D he adse t If OIS-D is 
unavailable, a telephone is available for contacting the Master Console. 

• All other DP activity 

• Users working on DPs will notify the TCMS MCOE through an OIS-D 
headset The MCOE will request from quality that an IPR be opened. If 
OIS-D is unavailable, a telephone is available for contacting the Master 
Console. 


6.1.1.3 Health and Status As sumptions . The following assumptions apply if the 
anomaly was reported by the health and status function to a TCMS MCOE 

Note: Network Manager, the health and status Cl, currently does not gather health and 
status of the FEPs or HIMs. This functionality will be included in release two of the CI. 


TCMS system health and status may be reported to the set MCOE through the 
network manager software, a system message, OIS-D, a phone call, or by visually 
checking subsystems. 
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• Only TCMS set anomalies are reported through the Network Manager. No health 
and status is available for POW's connected via the PON. 

• An IPR is opened by quality and dispositioned by the MCOE 

6.1.2 PROBLEM OWNERSHIP. Determining which organization(s) are 
responsible for problem resolution is not always easy. The Test Conductor takes the lead 
in determining the owner of the problem and O&M will support the Test Conductor, Test 
Integration, and System Engineer during problem identification. The following scenario 
describes the process used to determine ownership of a problem. 



Fig 6-1 

Problem Ownership Flow 


During End Item Testing, the Test Conductor and/or Test Integration will resolve disputes 
relative to problem ownership and high level trouble shooting activities. Detailed trouble 
shooting of TCMS hardware is always a TCMS O&M responsibility and any disputes will 
be handled by O&M. 
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6.1.3 JOINT PROBLEM RESOLUTION. Cases will arise where it is unclear who 
is responsible for anomaly correction. In these cases, a joint effort between two or more 
groups will be initiated by the test team. Depending on the type of anomaly, two or more 
of the following groups may be involved: 

• O&M, 

• Flight Systems Engineers, 

• SSPSE (Application software developers), 

• Sustaining Engineering, 

• Users, 

• Production Control 

• Software Product Assurance, 

• Network Services. 
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Fig 6-3 

Hardware Repair Flow 
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Fig 6-4 

LRU Repair Flow 
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6.2 HARDWARE ANOMALY RESOLUTION 

The TCMS reliability will be kept at an optimum level through the replacement of faulty 
hardware with previously verified LRUs. The verification of hardware spares will be 
performed in the OS A. The OS A is the set of TCMS hardware dedicated to the TCMS 
off-line functions. The primary purpose of the OSA is to minimize downtime of 
operational sets. 

TCMS Maintenance Engineering staff and Quality ensure the proper repair and 
verification of spare LRUs and subsystems. The spares are installed in the on-line test set 
by maintenance personnel. Failed LRUs will be handled in accordance with the TCMS 
Maintenance Plan, TS-TCMS-92003. Once the hardware is installed and restored to an 
operational state, the Maintenance Engineer will run diagnostics to ensure that the LRU is 
functional. The PRACA paperwork is then signed off by the diagnostic team and closed 
by quality. 

A Core maintenance design goal is to integrate the various levels of maintenance for 
improved fault isolation. Operational failures detected by System Integrity provides the 
failure symptoms and parameters for direct testing at the next level. 

Specific information about anomaly resolution can be found in the TCMS Maintenance 
Plan, TS-TCMS-92003. 


6.2.1 ON-LINE RESOLUTION. System Integrity is the on-line, non-intrusive 
testing of the TRS operational status. It provides for continuous health monitoring and 
status of peripherals, software, and network interfaces. It also controls and monitors 
redundant resources, monitors stored resources, and provides fault detection and isolation 
to a subsystem. 

Organizational level repair action will be to remove and replace, from verified spares, the 
LRU determined faulty by the various levels of troubleshooting and diagnostic 
maintenance. The subsystem will be re-tested with subsystem ORT and diagnostics and 
returned to operational status. System ORT and diagnostics are then run and the system is 
returned to operational status. 

If System Integrity detects an anomaly during a test, TCMS O&M personnel, along with 
the Test Conductor and Test Integration, will make a decision as to the criticality of the 
problem. If the problem is deemed minor by the involved organizations, an IPR will be 
opened, and the test may continue without immediate problem resolution. The problem 
will be resolved following the test If the problem is not minor and the test has not 
started, fault isolation will commence. If the problem is not minor and the test has started. 
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die Test Conductor will be notified and TCMS O&M will recommend a course of action 
to Test Integration. 


6,2.2 OFF-LINE RESOLUTION. System Maintenance is die off-line intrusive test 
of the sets operational status. It is composed of two integrated functions: set ORT and set 
diagnostics. It is active after the set has been configured and subsystems allocated but not 
operational. It provides a functional checkout of redundant and stored resources. System 
Maintenance, with System Integrity, provides the pre-operational fault detection and 
isolation to the subsystem. 

Subsystem Maintenance is the off-line intrusive test of a subsystem's operational status. It 
is composed of two integrated functions; subsystem ORT and subsystem diagnostics. It is 
typically active when a subsystem is not configured or allocated to a TRS. However, it 
can be activated on subsystems that are configured or allocated to a TRS. Subsystem 
Maintenance provides fault detection and isolation to an LRU within the subsystem. 

For COTS hardware, diagnostics rely extensively on BIT or routines supplied by the 
OEM. The Core design approach is to integrate COTS BIT into the ORT as much as 
possible. ORT provides the executive routines and additional testing not provided by BIT. 


6.3 SOFTWARE ANOMALY RESOLUTION 

Software maintenance of TCMS operating systems and system software will be performed 
by the TCMS Sustaining Engineering organization. Test application software maintenance 
will be performed by the SSPSE Organization. There are three categories of TCMS 
software that are discussed in this section: 

• COTS Software Vendor purchased products. 

• Test Application Software SSPSE developed software. 

• System Software Core developed and vendor purchased operating 

system software. 

For problems determined to be software related, the hardware platform(s) containing the 
defective software is investigated by the appropriate software group and loaded with a 
verified copy of the software module by O&M personnel. Once the platform is installed, 
O&M and Test Integration will ensure the software will operate as required. 

Additional information about the following paragraphs can be found in the TCMS 
Production Control Plan, K-CIE-63.2. 
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6.3.1 COMMERCIAL-OFF-THE-SHELF SOFTWARE. If an anomaly has 
occurred within a COTS product, it must be determined if: an actual "bug" exists; the 
software is corrupt; or the COTS package is unable to perform the needed function. 

In the case of software corruption, the solution is to re-install the COTS package from a 
CM verified copy. 

If it is determined a "bug" exists, the vendor will be contacted and a request will be issued 
to supply a patch to correct the error. Upon receipt of the patch or corrected software, it 
will be given to TCMS Sustaining Engineering for verification and then re-installed by 
O&M from the new CM verified copy. 

If an immediate update is unavailable, a test may be suspended until the update is received. 
If the software engineer, with Sustaining Engineering group concurrence, determine a 
previous version of the software will be able to accommodate continued test execution, 
the previous version will be used. 

If the software is unable to perform the needed task, the issue is turned over to TUG or 
the test team to determine the criticality and a solution. 


6.3.2 TEST APPLICATION SOFTWARE. If an anomaly has occurred within 
application software and has been determined not to be software corruption, the anomaly 
will be deferred to the Space Station Payload Software Engineering group. In the case of 
software corruption, the application will be re-installed by O&M from a CM verified copy 


6.3.3 SYSTEM SOFTWARE. System Software is divided into one of two 
categories depending on the status of the CEC contract While the CEC contract is still in 
effect the CEC is responsible for maintenance of the software package. Otherwise, 
TCMS Sustaining Engineering maintains all system software. The responsible group will 
correct any occurring anomalies. 


6.3.3. 1 Core Electr onics Contractor Responsibility . If an anomaly has occurred within 
a system software package and has been determined not to be software corruption, the 
system software package will be deferred to be corrected by the CEC if the CEC is still 
under contract for maintenance. If the software is corrupt, upon anomaly resolution the 
package will be reinstalled from a CM verified copy. 
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63 . 3.2 TCMS Sust aining Engineering Responsibility . At the end of the CEC contract, 
responsibility of system software will be that of the TCMS Sustaining Engineering 
department If an anomaly has occurred within a system software package at this point, 
the system software package is deferred to TCMS Sustaining Engineering for correction. 
If the software is corrupt, upon anomaly resolution the package will be reinstalled from a 
CM verified copy. 
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SECTION vn 
TRAINING 

Planning for the TCMS training of both end-users and support personnel is the 
responsibility of the Product Support - Logistics department This department will 
develop and implement a program that ensures the space and workstation requirements of 
this project Practical administrative training functions and activities will be integrated by 
the Training department The CEC is responsible for initial training of O&M personnel on 
all Core hardware and software components six months before transition of O&M 
responsibilities. Continuing training is the responsibility of the Product Support - 
Logistics department The OS A set will be utilized as a training set for the continuing 
training of users and support personnel as required. 


7. 1 OPERATIONS & MAINTENANCE TRAINING 

Technical training to support the use, management and monitoring of Core supplied 
software and hardware is the responsibility of the CEC. Initiall y, training in the use of 
hardware and software, supplied as part of the CEC contract will be provided by the 
CEC. On-going training will be conducted by the Logistics department 


7.2 USER TRAINING 

The CEC will train key user personnel in the use of all CEC-supplied software applications 
and hardware including DP training. These key personnel will support the training of 
additional employees. Initial user training on the use of TCMS software applications will 
be conducted by the SSPSE department after the applications are released into 
production. After user groups are trained, they will be responsible for on going training of 
additional employees. SSPSE personnel will support future training as needed. 


7-1 



TS-TCMS-92002 
Rev Basic 
January 29, 1993 


section vm 

SYSTEM ADMINISTRATION 

8. 1 SYSTEM ADMINISTRATION ROLES AND RESPONSIBILITIES 

Each shift will have at least one person in charge of operating system administration and 
maintenance. The responsibility of the System Administrators is to ensure the efficient 
operation of TCMS and to perform a wide variety of tasks that require special privileges. 
The system administrator will perform various maintenance tasks to prevent adverse 
effects on system performance. 

For additional information on System Administration see the TCMS Database 
Management/System Administration Plan, TS-TCMS-93xxx. 

8.1.1 EVENT LOGGING. System Administration will keep a log of all system 
modifications and system events. Each event, message, backup, or modification should be 
logged with the date, time, name of the person logging, and the circumstances surrounding 
the event An accurate log helps in diagnosing system problems and charting the growth 
and use of the system. 

8.1.2 ROLES AND RESPONSIBILITIES. System Administration has several 
duties to perform and the following lists a high level overview of these administrative 
duties. 

• Ensure the integrity of TCMS is not compromised through use of security 
mechanisms. 

• Ensure that adequate backups (regular copies of files) are made and stored for 
future use. 

• Handle problems related to use of limited computer resources (Le., disk space, 
number of processes, etc.). 

• Alleviate system communication stoppages due to failed connections. 

• Apply operating system updates and maintenance fixes. 
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8. 1.2.1 Roles and Responsibilities Summary . Tasks can be broken down into groups 

by how often they arc carried out The following list of tasks ranges from those that must 
be performed more often to those that need to be performed less often. 

As Needed Tasks: 

• Record all system modifications and events in a log. 

• Be on-call for emergency situations, crashes, power spikes, etc. 

• Maintain security of hardware, software, and data file access. 

• Coordinate system software downloads from the SPF. 

• Create and modify user configuration files. 

• Adjust system tuning parameters to maximize efficiency and performance. 

Daily Tasks: 

• Support backups. 

• Monitor usage levels. 

• Monitor for runaway processes. 

• Monitor disk space. 

• Monitor printer status. 

• Monitor audit trail output 

• Monitor communications links. 

• Monitor for unattended login sessions. 

• Perform security checks. 

Weekly Tasks: 

• Check file system integrity on all subsystems. 
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• Monitor printer spooler status reports. 

• Clear, trim, or truncate log files. 

• Use system performance tools to evaluate system efficiency. 

• Generate report of disk utilization. 

• Remove unnecessary temporary files. 

Monthly Tasks: 

• Support full system backup. 

• Archive critical files if changed. 

• Change administration passwords. 

Occasional Tasks: 

• Support upgrade of operating system, application software, and system software. 

• Locate large files and verify their purpose. 

• Find "orphan" files (no real user). 

• Locate sparse directories and compress if necessary. 

• Verify user/file permissions. 

8.2 SECURITY 

See the TCMS Security Plan, TS-TCMS-93XXX, for information on TCMS security 
including such topics as: physical security, network security, system access, and security 
recovery. 
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8.3 DATABASE ADMINISTRATION. 

Sec the TCMS Database Management Plan, TS-TCMS-93XXX, for information on 
TCMS database management Included in this document in Appendix A is a copy of the 
TCMS Database: Roles and Responsibilities Memorandum Of Understanding (MOU). 

The purpose of the MOU is to document the roles and responsibilities associated with the 
operation, administration, and maintenance tasks concerning various TCMS Databases. It 
describes the different TCMS databases, along with the tasks required to properly manage 
them. An attached matrix assigns responsibilities to the associated tasks and databases. 
The roles and responsibilities contained in the matrix represent post CEC involvement 
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SECTION IX 
RISK ASSESSMENT 

The Disaster Recovery Plan (DRP) will be published using "RiskWatch" software as an 
aid in determining risks. 

Note: " RiskWatch ” is a COTS program that will generate portions of the TCMS Security 
Plan and Disaster Recovery Plan. It was developed with the ability to generate charts 
and tables with NASA specific risks included. 

The "RiskWatch" software requires that all system assets be defined such as the cost of: 

• COTS equipment 

• System hardware 

• Facilities 

• DPI 

• Operating System 

• UPS 

• HVAC 

• Alarms 

• Software to be developed 

• Safeguards 

After defining the cost and types of risks, vulnerability, severity, and predictability must be 
assessed. The types of risks that may occur to NASA are included in the "RiskWatch" 
software. The major risks involved include: natural disasters, fire, bomb threats, and 
accidents. Virus and " h ac k er" threats will also be included although not specifically part 
of the "Risk Watch" software. 

Vulnerability is the probability of a risk occurring to a particular asset If there is a very 
small probability of a risk occurring, the asset is nearly, but not absolutely, invulnerable. 
Severity refers to how disastrous the results will be if a risk occurs to a particul ar asset If 
only a small financial loss or a short processing delay results, the risk has an extremely low 
severity. 

All this information is then entered into "RiskWatch," that then generates a questionnaire 
that is used to gather more relevant data for the system. After the answers to the first 
questionnaire are entered into "RiskWatch" a second questionnaire is generated. This final 
questionnaire then gathers the remaining data need for the software to be able to generate 
the risk analysis. As part of the risk analysis, several tables and charts arc generated which 
show the cost involved in implementing each section of the TCMS Disaster Recovery 
Plan, TS-TCMS-93XXX. 
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The completion of the TCMS DRP will be delayed until the "RiskWatch" software has 
been delivered. Upon arrival of the "RiskWatch" software, a comprehensive DRP will be 
generated addressing the issues outlined in this section. 


9.1 RISK ANALYSIS 

This paragraph will be updated to contain the actual risk analysis generated from 
"RiskWatch" when it becomes available. 


9.2 RISKS 

9.2.1 NATURAL DISASTERS. Natural disasters associated with adverse weather 
and hurricanes are anticipated in the emergency preparedness planning, outlined in KSC 
Hurricane Handbook, KHB 1040.2f. During the period of June 1 through November 30, 
the KSC area is subject to high winds and heavy rains. Precautions required are 
implemented in coordination with government, affected contractor organizations, and the 
KSC Emergency Preparedness Officer. 

KSC guidelines will be followed for lightning protection. TCMS equipment will be 
protected by lightning prevention equipment within the facility. 


9.2.2 FIRE. Appropriate physical safeguards are also being planned to protect 
TCMS, including a fire detection and suppression system. The KSC fire department will 
be wired into the fire detection system. Fire prevention and protection responsibilities arc 
outlined in KMI 8838. IB, "Fire Protection, Fire Prevention and Rescue." In the 
implementation of the procedure, safety of personnel will be given primary consideration. 

All fires will be properly reported according to established procedures and all persons not 
engaged in fire fighting or other emergency duties, will be evacuated to safe areas. 
Periodic inspections are conducted by the KSC Fire Department to identify deficiencies in 
housekeeping, safety, and fire control equipment All personnel receive periodic training 
in the use and function of fire safety equipment by the KSC Fire Department 


9.2.3 BOMB THREATS. Any person receiving a bomb threat at KSC has 
instructions readily available for handling and responding to the call per KMI 1620.5A, 
Bombs and Bomb Threats. Immediate instructions are on the back of all KSC phone 
books. Procedures for evacuating and securing the station include emergency shutdown 
and identification of responsibilities for securing the area. 


9-2 


TS-TCMS-92002 
Rev Basic 
January 29, 1993 


9.3 EMERGENCY PREPAREDNESS 

Detailed plans and procedures for dealing with fires natural disasters, environmental 
factors and other contingencies have been developed for use at KSC to cope with any 
emergency or disaster that may occur. The Emergency Preparedness Plan, KHB 1040. ID, 
includes the necessary preparatory actions and procedures to be taken for the protection 
of personnel, property, and material resources at KSC in the event of one or more of the 
following contingencies. 

• Hurricanes 

• Civil Disturbance 

• Fire and Explosion 

• Loss of Utilities 

• Defense Readiness 

• Peacetime Radiological Incidents 

• Inadvertent Space Vehicle/Missile Impact 

• Emergency Medical Operations 

• Adverse Weather/Tomadoes 


9.3.1 CONTINGENCY PLANNING. Contingency plans will be developed by 
O&M for TCMS contingencies. These plans will inform the O&M personnel the course 
of action to take when any contingencies occur. Examples of such situations would be: 

• SPF host unavailable; 

• Global bus, local bus, etc. unavailable; 

• Data loss or damage; 

• Power outage; 

• PON access unavailable; 

• Fire and other natural disasters; 

• Set master AP unavailable. 

This list is not meant to be exhaustive and does not include many of the possible 
contingencies. The following paragraph demonstrates an example of a contingency plan 
when the SPF host(s) is unavailable. 


9.3. 1.1 SPF Host Unavailable C ontingency Plan . SPF Host Unavailable definition: 

The SPF host is unavailable when communication to other TCMS subsystems is not 
possible. 
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One SPF Host Unavailable: If one of the two SPF hosts is unavailable, O&M will notify 
as many users as possible by system message, phone, or OIS-D, and redirect them to the 
second SPF for their operations. Activities that are only possible using the unav ailab le 
SPF will be postponed until it's brought back on-line. O&M will reconfigure as needed to 
redirect all activity to the second SPF host then troubleshoot and repair the unavailable 
host This situation will not hinder active tests but may postpone scheduled tests or 
events. SPF peripherals such as disk arrays, 9-track tape drives, and laser printers will be 
available. However, the hosts line printer will be unavailable. Users working from POWs 
or DPs may have communications halted momentarily but will be able to continue work 
through the second SPF host 

Two SPF Hosts Unavailable: If both SPF hosts are unavailable, O&M will attempt to 
notify as many users as possible by telephone or OIS-D. All SPF activities will be 
postponed until one or both of the hosts are brought back on-line. This situation will not 
hinder active tests but will alter further scheduled events. O&M will begin 
troubleshooting and repairing the hosts to bring them back on-line as quickly as possible. 
All SPF peripherals will be unavailable. All users will have communications halted until 
one of the hosts is repaired. 


9.3.2 CONTINGENCY OPERATIONS. In case of fire or other environmental 
danger or damage, KSC fire department and/or other appropriate disaster-trained 
personnel will assume control of the situation, ensuring that all personnel have been safely 
evacuated. Upon emergency services approval for computer personnel to re-enter the 
area, TCMS Hardware/Maintenance/Engineering personnel will begin immediate 
assessment of damage and proceed to bring sufficient equipment on-line to resume 
operations as soon as practical. 

Concurrently, clean-up operations will be initiated to bring remaining equipment on-line 
for auxiliary support 

If software is lost (Le., the system disk is destroyed), software backups will be utilized to 
restore the system provided the appropriate hardware is available. Secure and protected 
storage of media for all backup system and application software and data files reside in an 
undetermined off site storage location. 
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Subject: TCMS Databases: Roles and Responsibilities 
Purpose 

The purpose of this MOU is to document the roles and responsibilities associated with the 
operation, administration, and maintenance tasks concerning various TCMS Databases. 
This memorandum describes the different TCMS databases, along with the tasks required 
to properly manage them. The attached matrix assigns responsibilities to the associated 
tasks and databases. The roles and responsibilities contained in the attached matrix 
represent post HSSC involvement The roles and responsibilities of HSSC and their 
transition to CM/PGOC must still be negotiated. 


TCMS Databases 

The databases described below will either be a part of the TCMS or will support TCMS 

activities. 

Databases residing on the SPF: 

1. Test End Item Data Bank - Contains all the measurement and stimulus specifications 
that define the interface between a Test End Item (TEI) and the TCMS Core system. 
Measurement and stimulus specifications are collectively referred to as Function 
Designators (FDs) and are identified by a Function Designator Name. A Function 
Designator may be composed of Compiler Data, Calibration Data, Hardware Data, 
and FD Addressing data. In addition, the Data Bank contains System Validation 
Criteria which identifies valid Data Bank clients and their authorization level, and 
defines the data subgroups used to validate entry. The TEI data bank also contains 
Data Bank Revision Data, which is composed of transaction auditing data, creation 
date, date of last update, update user, and an incremental revision level 

Note: Data cached from the MODB may be stored in an Oracle RDBMS by the 
TCMS BULK INPUT (TBI) CSCI prior to incorporation in the TEI Data Bank and 
Link Configuration Database. This implementation detail is currently TBD. 

2. Link Con figuration Database - The Link Configuration Database is the repository for 
all the information required by the Core systems to acquire and process Link 
Configuration data. Link Configuration data describes the configuration of the data 
links that provide the front-end communications path between the TCMS Core 
systems and a Test End Item. 
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3. Function Designat or Directory (FDD) - Contains the Compiler, the selected 
Hardware, and FD Addressing data for each Function Designator selected for a Test 
Configuration extracted from the Data Bank. Only one set of Hardware and FD 
addressing data for each Function Designator is contained in the FDD. Each FD is 
assigned a System Software Reference Number (SSRN) used to access the FD in the 
Test Configuration. This FD information provides the data to construct the On- line 
Data Bank (OLDB) and the FEP tables which direct the processing of FDs. 

4. A pplication Software Libraries - Contains both development and configuration 
managed software. These include: Test Application Software, Simulation Software, 
Dynamic Displays, and Test End Item Software. These libraries and their associated 
supporting software will be provided by the Software Support Environment (SSE) 
for TCMS. 

5. Hardware Resource Database - Hardware Resource Data is used to identify 
Hardware Resources and to allocate them to a Test Resource Set These data are 
both functional and physical in nature and may include a reference designator, 
function description, physical port id/address, class, type, location, and serial number. 

6. System Software Library - Contains TCMS system software which is under CM 
control. 

7. Master Cl ient Profile Database - Contains data describing each valid user of the 
TCMS. This data includes associated permission levels, groups, SYSCONs, TCIDs, 
Partitions, and Support Roles for which the individual user is authorized. 

8. Real Time Client Profile Database - A subset of the Master Client Profile Database, 
this database is automatically created by the system and downloaded to the Set during 
the Configure process in support of specific test activities. 

9. Su pport Role Database - Used by a system administrator to view, define, modify and 
delete support roles which specify which HTD/HRT functions are available to a given 
"role" or "class" of user. 

10. Client Sup port Area Database - Used to track and maintain all requests and problem 
reports relating to TCMS Hardware and Software anomalies. The location and tool 
used for this database is TBD. 

1 1. Resource Utilization Scheduling Database Used to schedule the availability of TCMS 
hardware resources. The location and tool used for this database is TBD. 
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12. Hardware CM Database Contains information concerning the TCMS hardware 
configuration. These data include serial number, description, revision number, and 
location. The location and tool used for this database is TBD. This database may be 
hosted on the existing ALRUTS or Production Tracking System (PTS). 

13. Preventive Maintenan ce Database - Used to keep track of and schedule the preventive 
maintenance activities for the TCMS Set (and SPF Set) hardware. The location and 
tool used for this database is TBD. 


Databases residing on the PDR and DBS: 

1. Archive Location Catalog - Contains the data retrieval locations (PDR, DBS, etc.) for 
both processed and raw recorded data. Each entry (which also maps to a m edia 
volume) is identified by a volume ID, Mission ID, Test Configuration Identifier 
(TCID), TRS ID, start and stop time, etc. Also included is a time association table for 
converting Greenwich Mean Time (GMT) to Coordinated Universal Time (UTC) for a 
TRS. This database is populated as volumes are filled during recording in a TRS. The 
database may then be accessed to retrieve the location of the recorded data and to 
convert times. 

2. Other Databases - TBD. 


Roles and Responsibilities 

The following tasks relate to the responsibilities of managing the above mentioned 

databases. 

• Data Administration - Ensuring that the data placed in the database meets the specific 
rules and conventions of consistency, validity, accuracy, and format 

• Data Maintenance - Making the entries, deletions, and changes to the data in the 
database. 

• Data Source - Indicates the organization responsible for supplying the Data/Files 
contained in the Database/Library. 

• User/Svstem Supp ort - Servicing user requests including individual backup/restore 
operations, increasing file space allocations, facilitating special group access to specific 
files, etc. 
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• Security - This list is a subset of the overall TCMS security function. Determine 
which data items need special security protection, which users or classes of users arc 
authorized to see, create, update, or delete what data in the database. Maintain 
security access tables. Client Profiles, and Support Role definitions. Create 
procedures to implement security measures. 

• Configuration Management - Establish and implement a formal system of control to 
assure that no unauthorized changes are made to the baseline software and data 
contained within the databases. Revision history as well as build/class information 
must be maintained in accordance with the TCMS Production Control Plan, K-CTE- 
63.2. Procedures must be developed to facilitate the end user’s compliance with this 
plan and to prevent accidental or intentional corruption. SSE provided CM Tools will 
be used to perform portions of the CM function. 

• Initial Loading - Populate the database with its initial data values and resolve any 
inconsistencies that arise during this process. 

• Disk Management - Periodic backup of database files to archive media. Both full and 
incremental backups must be scheduled and performed. Disk defragmentation will be 
performed periodically to increase contiguous free space to maintain system 
performance. 

• Housekeeping - Determine and execute the policies for retention and deletion of data 
and/or data migration. 

• Space Allocation - Maximize usage efficiency by periodic measurement of file 
utilization to determine appropriate restructuring. 

• Performan ce Monitoring / System Tuning - Analysis of key performance criteria to 
assess relative performance levels. Adjusting physical database parameters to improve 
performance. 

• Expansion - Creation, implementation, and testing of additional physical or logical 
volumes. 

• Database Modification - Addition of new fields or keys, changing the size of existing 
fields, reorganization of databases or indices. 

• Error Dete ction and Problem Resolution - Data corruption problems are flagged and 
resolved. Source of problems are tracked down and corrected. 

• Software Upgrades - Installation and testing of new releases of COTS database 
software. 
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• Data Conversions - Execution of conversion procedures to insure data compatibility 
with new Database SW/HW. 

• Regression Testing - Testing of all database functionality when new releases of 
software or hardware which interact with TCMS Databases are introduced. 

• Disaster Recovery - Procedures for restart and recovery following system outages. 
Restoration of database contents from backups in the event of loss of records or of 
catastrophic destruction of entire files. 

Organizational Definitions 

The following abbreviations are used in the attached matrix to describe the responsible 

organizations: 

• User - This refers to the TCMS Applications Software Development group and the 
Production Control group. This is not intended to be construed as the "user of the 
data in the database" but rather, the "user community", in contrast to the other listed 
organizations. 

• Sust. Eng. • This refers to the TCMS Sustaining Engineering organization, (due to 
size limitations this may be abbreviated as "SE") 

• Q&M * This refers to the TCMS Operations & Maintenance group. 
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Appendix B 

TCMS SYSTEM DESCRIPTION 


B.l GENERAL 

TCMS is a major KSC/Core Electronics Contractor (CEC) developed system supporting 
the Space Station Freedom Program (SSFP) at KSC and Johnson Space Center (JSC). 

The equipment consists of Commercial-Off-The-Shelf (COTS) and custom hardware, 
software, and firmware. It is configured into various subsystems and sets to meet the 
automation requirements of the space station checkout activities. This section describes 
the major hardware components of TCMS. Figure B-l shows a high level view of the 
TCMS architecture. Figure B-2 shows a typical TCMS operational set configuration 

B.2 TCMS SETS 

TCMS is configured into sets and subsets of end-item equipment at various locations. The 
CEC will deliver three sets (configured as six half sets) for support of the SSPF test stand 
area, one set to the OS A, one set to the hazardous facility, one set to the CAF/CSF at 
JSC, and SNO. TCMS sets are configured from the following assemblies: 

B.2.1 DISPLAY PROCESSOR. The Display Processor (DP) is the system 

interface to the user within the Core distributed architecture. It includes a 32 Bit Central 
Processing Unit (CPU) running UNIX based ULTRIX, a keyboard, a pointing device, a 
primary display, up to three slave monitors, a removable media device, and an MS DOS 
compatible floppy disk drive. The DPs directly interface with die Display Network 
Subsystem (DNS) for accessing the Application Processor (AP), Processed Data Recorder 
(PDR), Data Base Subsystem (DBS), Service Network (SN), Software Production 
Facility (SPF), and external systems such as Payload Data Management System (PDMS). 

B.2. 2 APPLICATION PROCESSOR. The Application Processor (AP) is the 
UNIX based data processing node within the Core distributed architecture. It is a 
computation intensive subsystem that primarily executes real time system services and test 
application programs. It consists of two 32 bit CPUs, a 500 megabyte hard disk drive 
(upgradeable to 2 gigabytes), and a removable media device. It interfaces directly with the 
DNS for access to the DPs and through a Buffer Input/Output Processor (BIOP) to the 
Real Time Network (RTN). 
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FIGB-2 

TYPICAL TCMS OPERATIONAL SET CONFIGURATION 
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B.2.3 FRONT END PROCESSOR- The Front End Processor (FEP) is a universal 
hardware element that performs the data processing necessary to support a wide variety of 
synchronous and asynchronous test article control and data acquisition at the front end 
interfaces. It consists of several CPU and interface modules housed in a Versa Module 
European (VME) bus chassis. The specific interfaces required govern the configuration of 
this subsystem. The FEP has the capability to process all known Space Station, Payload, 
and Ground Support Equipment (GSE) data types by configuration of interface canls, 
custom software, and customized high performance filter modules. The FEP 
communicates to the other subsystems by way of the RTN through a BIOP. 

B.2.4 REAL TIME NETWORK. The Real Time Network (RTN) provides 
message and data communication capability for attached processors. The RTN utilizes star 
topology with hosts connected to the central node through dedicated, high speed, point- 
to-point links. Through access control of shared data storage area and message routing 
tables, the hosts attached to the RTN can be configured into multiple Test Resource Sets 
(TRSs) to support parallel operations. 

The RTN consists of the Common Data Buffer (CDBFR), host resident BIOPs, and host 
resident Monitor Input/Output Processors (MIOPs). The BIOP supports the exchange of 
single, multiboard, and homogeneous data sets as well as messages. Error detection and 
correction and/or error reporting mechanisms ensure the integrity of the information. The 
MIOP is a unidirectional link that routes data passing through the RTN to a Processed 
Data Recorder (PDR). 

B.2.5 DISPLAY NETWORK SUBSYSTEM. The Display Network Subsystem 
(DNS) provides a communication path for system operations. The DNS provides the 
capability to isolate the DPs and APs into Local Display Buses (LDPBs) with filtered 
interfaces to the Global Display Bus (GDPB). The LDPB allows all local traffic to be 
generated without interfering with data traffic on the GDPB. 

B.2.6 SERVICE NET. The Service Net (SN) provides a communication path for 
maintenance operations. The SN provides capability for remote and local access to 
operation and maintenance services for applicable TCMS hardware. 

B.2.7 HARDWARE INTERFACE MODULE. The Hardware Interface Module 
(HIM) acts as the front-end element of TCMS and is connected to the GSE Data Bus for 
communications with the FEP. A FEP may control up to sixteen HIMs via a ground dat a 
bus. The modular design of the HIM accommodates several types of interfaces depending 
upon the particular configuration required. 

There are two basic types of HIMs, slave and standalone (also known as a smart or Local 
Processor Control (LPC) HIM). The slave HIM is always connected to a FEP and its sole 
function is to transfer measurement data from a GSE device to the FEP, or to pass a 
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command from the FEP to the specific GSE device. Thus, there is no algorithmic 
processing of measurements or command generation in the slave HIM. The standalone 
HIM interfaces to GSE equipment as in a slave HIM, but it gathers measurements and 
issues GSE commands without requiring a FEP. 

B.2.8 PROCESSED DATA RECORDER. The Processed Data Recorder (PDR) 
records data from the RTN to support near real time retrievals and post-test retrievals. 

The data consists predominantly of preprocessed test article data from a FEP. The PDR 
records on two different media simultaneously. One media. Temporary Archive Media 
(TAM), supports the near real time retrievals and the other. Permanent Archive Media 
(PAM), supports a historical record. The PDR interfaces with the RTN for data 
recording. 

B.2.9 DATA BASE SUBSYSTEM. The Data Base Subsystem (DBS) provides the 
data management and data handling functions to support the data display and analysis 
performed during and after tests. The DBS supports real rime data storage and retrieval 
as well as media library data base management During a test the DBS supports data 
retrieval and analysis of the PDR recorded data. 

B.2.10 DATA MANAGEMENT SYSTEM. A Data Management System (DMS) kit 
is an integrated set of electronic units and an interface device to connect these components 
to a host computer. DMS kits are used for code verification and test support in place of 
the flight hardware. 

The DMS kit typically contains a TCMS Simulation Interface Buffer (SIB) and a set of 
DMS Functional Equivalent Units (FEUs). The SIB is the interface device within the 
DMS kit that provides the interface bridge to the Space Station Freedom environment, 
including the loca l buses and networks. The FEUs are non-flight versions of various space 
station flight components. 

The DMS kit configuration will vary depending on mission specific requirements and 
phase of testing. The kit operational components are: 

• Simulation Interface Buffer 

• Local Control Workstations (LCWS) 

• System Development and Diagnostic Subunit (SDDS) 

• Network Monitor Subunit (NMS) 

• Network Simulator Subunit (NSS) 

• Functional Equivalent Units 

• Intermediate Rate Gateway (IRGW) 

• Intermediate Gateway (IGW) 

• Multiplexer/Demultiplexer (MDM) 

• Ring Concentrator (RC) 
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• Standard Data Processor (SDP) 

• Mass Storage Unit (MSU) 

• Multipurpose Applications Console (MPAC) 

• Time Generation Subunit (TGS) 

The space station DMS buses and networks include MIL- STD 1553B local buses, ANSI 
X3T9.5/83-15FDDI networks, and an EIA RS-422A time distribution bus. 

B.2. 1 1 PATCH PANELS. The TCMS Patch Panels provide for the interconnection 

of TCMS subsystems and the connection with systems external to TCMS. SSPF patching 
is accomplished in the Central Communications Room (Rm. 1025), the Networks Room 
(Rm. 1026), the Communications & Tracking Room (Rm. 1062), the Test & Simulation 
Room (Rm. 2021), the Control Support Room (Rm. 2023), High Bays, Intermediate 
Bays, and Off-line labs (Rms. 1077, 1083 & 1098). Payload Spin Test Facility - 
Replacement (PSTF-R) patching is accomplished in the Flight Data Communications 
Room (Rm. 117). Patching for the Hazardous Operations Support Facility (HOSF) is 
accomplished in the HOSF Control/User Room (Rm. S109). 

Currently there are 97 DMS Kit patch racks, the majority of them being in SSPF 
Rm. 2021. Because of the complexity involved in patching this quantity of racks, default 
patching configurations will be used as much as possible as long as modifications can still 
be made as required. 

Figure B-3 is a diagram of the patching scheme used on TCMS. This diagram is 
preliminary and has areas of uncertainty shown with question marks. TCMS O&M will 
revise this drawing when the interfaces in question are finned up. For more detaile d 
information on TCMS patching, and a description of all the interfaces needed to support 
testing in each of the three facilities (SSPF, PSTF-R, and the HOSF), reference the TCMS 
Communications and Patching Plan (TS-TCMS-92004). 
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FIG B-4 

SPF ARCHITECTURE 


B.2. 12 SOFTWARE PRODUCTION FACILITY. The SPF is the hardware set used 
for development and configuration management of applications and simu l a tion software. 

It allows software developers to perform final compiles on the target subsystems and 
serves as a local repository for downloaded Master Object Data Base (MODB) data, build 
data, and test configuration functions. The SPF is composed of the following baseline 
equipment: 


• Host Computer Systems 

• Cluster Controller to Disk Drive Interface 
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• Disk Drive Storage Unit 

• Tape Drive 

• Target APs 

• Target PDR 

• Target DBS 

• Line Printers 

Figure B-4 describes the SPF architecture. For a more detailed description of the SPF 
equipment see Hardware Design and Maintenance for the SPF HWCI (83K03802). 

B.2.13 NETWORK INTERFACES. TCMS internal network interfaces include the 
DNS, the SN, and the RTN. The DNS; which consists of the TCMS Global Bus, the 
GDPB, and the LDPB, provides the communication path for normal system operations. 
The SN provides the communication path used for maintenance and diagnostic operations. 
The RTN provides for test data flow between the FEPs and the AP and PDR. In addition, 
it provides subsystem interfaces, message routing, common data storage, and a data 
logging interface. Through control of the subsystem interfaces, the RTN provides for the 
addition, deletion, and logical partitioning of attached resources into Test Resource Sets 
(TRSs). 

TCMS external network interfaces are accessed via the Payload Operations Network 
(PON). The PON is an administrative network that provides connectivity to PDMS, 
Payload Office Workstations (POWs), the Production Tracking System (PTS), Computer 
Aided Design/Computer Aided Engineering (CAD/CAE), Broadband Communication 
Distribution System (BCDS), and Program Support Communications Network Internet 
(PSCNI). Once approved. Security ESRs that are now pending will protect TCMS and 
Test Articles from access by unauthorized clients. 

Figure B-5 describes the TCMS network interfaces. For mote detailed information on 
TCMS network interfaces, refer to the TCMS Communications and Patching Plan (TS- 
TCMS-92004). 
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APPENDIX C 

TCMS SOFTWARE ALLOCATION AND INTERACTION 
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PURPOSE: The purpose of the Allocation portion of the document is to show the 
individual TCMS Hardware platforms and all of die system and COTS software that is 
either resident on or interactive with the particular HWCI. The second part of the 
appendix shows the individual CSCIs, and how they interact with each other. The 
direction of the arrow shows the direction of the data flow. 

This document is to be used by TCMS O&M as a tool to guide in the locating of software 
related anomalies. It is intended to be a helpful tool that can be used for ease of reference 
and speed in the tracking and correcting of software related anomalies. 
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